Interpretato vs.Linguaggi compilati per siti Web (PHP, ASP, Perl, Python, ecc.)

Question

Costruisco siti web basati su database.In precedenza ho utilizzato Perl o PHP con MySQL.

Ora sto iniziando un nuovo grande progetto e voglio farlo in modo che si traduca in... sito più reattivo possibile.

Ho visto diverse pagine qui in cui le domande su come ottimizzare PHP vengono criticate con varie versioni di "non vale la pena fare di tutto per ottimizzare PHP poiché è un linguaggio interpretato e non farà molta differenza".

Ho anche ascoltato varie discussioni (specialmente sul podcast SO) sui vantaggi di compilato vs.lingue interpretate, e sembra che sarebbe nel mio interesse utilizzare un linguaggio compilato per servire il sito invece di un linguaggio interpretato.

Ciò è possibile anche in un contesto web? Se sì, quale sarebbe una scelta linguistica ragionevole?

Oltre alla velocità, un vantaggio che prevedo è la possibilità di trovare bug in fase di compilazione invece di dover eseguire il debug del sito web.È ragionevole aspettarselo?

Answer 1

Quello che puoi fare è quello che fanno più siti web ad alto traffico (come Facebook o Twitter), ovvero scrivere il tuo algoritmo di "consumo di CPU" in un plug-in C.

Ad esempio, potresti scrivere a estensione PHP se prevedi di utilizzare PHP o a Estensione rubino se prevedi di utilizzare Ruby / Ruby on Rails, ecc.

In questo modo, puoi mantenere il tuo codice ottimizzato semplice e facile da mantenere (potrebbe essere molto più difficile gestire le richieste da C piuttosto che da PHP), pur avendo un nucleo di background forte e solido (perché è compilato e il compilatore ti dice cosa i problemi sono in fase di compilazione)

Answer 2

Se si dovesse andare a costruire una nuova lingua ... e si avvicinò con tutte la semantica ed era completa, e si aveva un po 'scatola magica che ha avuto un interruttore tra rendendo il linguaggio compilato contro interpretata, la versione compilata sarebbe più veloce rispetto alla versione interpretata.

Perché? Perché compilazione porta i tuoi semantica fino a un livello più basso nella macchina, che significa che può eseguito molto più velocemente, mentre interpretare significa la semantica di lingua saranno tradotte da alcuni cosa (cioè l'interprete), quando l'utente utilizza effettivamente il tuo sito.

Detto questo ... che non significa necessariamente che il vostro sito sta per il 100% correre più veloce su un linguaggio compilato vs un linguaggio interpretato. Ci sono interpreti là fuori che sono molto veloci al giorno d'oggi per le varie lingue (vale a dire PHP), e ci sono ottimizzatori anche per linguaggi interpretati che li rendono più veloce persino ancora.

Ci sono molte altre cose che vanno nelle prestazioni del vostro sito che sono agnostico della lingua scelta. configurazione hardware, la configurazione del database, la topologia di rete, ecc Queste cose possono avere un impatto maggiore su di voi. Vorrei suggerire di misurazione per essere sicuri.

Per quanto mi riguarda, trovare bug in fase di compilazione è un enorme risparmio di tempo, quindi tendo a preferire linguaggi compilati che sono fortemente tipizzati. Mi permette di ottenere il mio lavoro fatto più veloce, ma questo non lo rende oggettivamente la migliore opzione. Alcune persone non hanno problema di scrittura di codice debolmente tipizzato, e l'esecuzione di suite di test su di loro per verificare la loro funzionalità, che penserei avrebbe funzionato altrettanto bene.

Answer 3

IMHO è abbastanza un non-senso per scrivere un web app complesso utilizzando un linguaggio compilato, in quanto dà non benefici contro una serie di problemi di gestibilità.

C'è un sacco di modi per salire fino performance e scalabilità in un linguaggio di script, sia a livello linguistico che a livello di sistema, essendo le prestazioni minori acquisiscono finalmente disponibile con un linguaggio compilato totalmente influente.

D'altra parte trovo molto utile per essere possibile seguire uno schema di caccia sviluppo e bug agile, semplicemente cambiando il codice e vedere i risultati.

Answer 4

Perl non è un linguaggio interpretato: è compilato in bytecode, in modo da pagare il prezzo di interpretazione solo quando viene avviato l'eseguibile perl. Così, quando lo si utilizza con Apache, non utilizzare CGI ma mod_perl.

Qualunque cosa tu faccia, il tempo di sviluppo è probabilmente andando a superare ampiamente i tempi di risposta se si sceglie una lingua che non è adatto per la programmazione web o non dispone di buone biblioteche per sostenere quello che devi fare. Per esempio. Non avevo mai prendo C o C ++. Se non si desidera una web app che è velocissima ma buggy e 6 mesi di ritardo.

Answer 5

Tomcat è un modo comune di usare linguaggi compilati per distribuire le pagine web, ma prima di andare troppo lontano, seriamente in considerazione che cosa i vostri colli di bottiglia velocità saranno . Ci sono alcune principali fonti di rallentamento nelle applicazioni web:

1. latenze di rete
2. supporti statici, in particolare le immagini
3. query di database
4. codice di elaborazione lato server
5. codice di elaborazione lato client

1 e 5 non hanno davvero molto da fare con questa domanda.

2 sarà rilevante se si dispone di molte immagini che variano da una pagina all'altra. Se questo è il caso, i browser client non faranno come ad un buon lavoro di caching, e ogni pagina-carico ci vorrà del tempo. In questo caso, è molto probabile che il vostro linguaggio lato server non sarà notato, perché il sovraccarico da supporti statici dominerà.

3 è probabile che sia un fattore più grande di 4 per un sacco di applicazioni. Se si dispone di pochi dati, ma si fa un sacco di elaborazione, quindi 4 possono dominare, ma per il resto, 3 dominerà anche se si sta utilizzando un linguaggio interpretato.

La gente può chiedere: "Perché ottimizzare php?" perché il 2 e 3 sono spesso più importante comunque. Spesso, una buona sta per essere una migliore (e più facile) ottimizzazione.

Answer 6

Ci sono un sacco di parti che va in un'applicazione web. Il tempo impiegato dal livello di applicazione non ha bisogno di essere grande. Per una tipica applicazione, i più grandi maiali sarebbero in server web e nella banca dati. Sostituzione di PHP con un cgi binario non sta per cambiare questo.

Inoltre, mentre le parti interpretate di PHP possono essere un po 'lento, questa è solo una piccola parte di ciò che accade nella esecuzione di uno script PHP. Tutte le funzioni che sono forniti come parte del linguaggio sono implementati in codice nativo. Ad esempio, quando si chiama una funzione come preg_match, si chiamerà fuori una libreria di codice nativo e lasciar fare il suo lavoro. Ciò significa che c'è meno l'interpretazione effettiva succedendo quanto si possa pensare.

Ci possono essere alcuni casi in cui utilizzando un linguaggio diverso da quello PHP potrebbe essere utile, ma questi sono casi speciali. In generale, non c'è nulla da guadagnare qui.

Answer 7

La latenza della rete è di gran lunga il più grande fattore determinante in questo argomento. Infatti, la latenza di rete è tanto di un fattore che rende considerazioni sulla lingua piuttosto irrilevante da un problema di prestazioni. Quindi ... vai con quello che sai. Utilizzare la lingua che si sta più comodi e più produttivo con e altre considerazioni possono essere elaborati come si va avanti. Ora, detto questo, è sempre divertente provare cose nuove e imparare cose nuove può diventare un'ossessione, quindi se il progetto è una personale che consente la possibilità di sperimentare, bene, con tutti i mezzi .....