Apache o lighttpd [chiuso]

Question

Per lo sviluppo, utilizzo uno stack LAMP locale, per la produzione sto utilizzando Django Container di MediaTemple (che adoro BTW). Il contenitore di MT utilizza lighthttpd. Onestamente non ho mai avuto altre esperienze con esso. Ho sempre usato Apache. Ho letto alcune cose:

• Onlamp
• TextDrive
• Linux.com

Ecco le domande:

• Quali sono i punti di forza di uno rispetto all'altro?
• Mi trarrebbe vantaggio l'uso di lighthttpd sulla mia configurazione di sviluppo?
• Che ne dici di usare entrambi? L'articolo di Linux.com parla dell'uso di lighttpd con Apache.

Answer 1

Il modo in cui l'interfaccia tra il server Web e Django potrebbe avere un impatto ancora maggiore sulle prestazioni rispetto alla scelta del software del server web. Ad esempio, mod_python è noto per essere pesante sulla RAM.

Questa domanda e le sue risposte trattano anche altre opzioni del server web.

Non sarei interessato ai problemi di compatibilità con il software client (vedi Commento di MarkR ) . Non ho avuto problemi del genere quando servivo Django usando lighttpd e FastCGI. Mi piacerebbe vedere un ecosistema diversificato di software client e server. Avere un buon standard è meglio di un prodotto di fatto di un singolo fornitore.

Answer 2

Il vantaggio di entrambi: Apache è più potente ed estensibile (inutile se non hai bisogno di quel potere, ma comunque ...) e lighttpd è più veloce nel contenuto statico. L'idea è quella di suddividere il tuo sito in contenuto statico (css, js, immagini, ecc.) E codice dinamico che scorre attraverso Apache.

Non sto dicendo che non puoi fare molto con lighttpd da solo. Puoi e lo fanno le persone.

Se stai usando lighttpd esclusivamente sul tuo server di produzione, prenderei seriamente in considerazione il mirroring sui tuoi server di sviluppo e gestione temporanea in modo da sapere esattamente cosa aspettarti prima di implementare.

Answer 3

Per pagine Web puramente statiche (.gif, .css, ecc.) con n richieste HTTP da indirizzi IP distinti: 1. Apache: esegue n processi (con mod_perl, mod_php in memoria) 2. lighttpd: esegue 1 processo e 1 thread (è possibile assegnare m thread prima di avviarlo)

Per pagine Web puramente dinamiche (.php, .pl) con n richieste HTTP da indirizzi IP distinti: 1. Apache: esegue n processi (con mod_perl, mod_php in memoria) 2. lighttpd: esegue 1 processo lighttpd grazie all'I / O asincrono ed esegue m processi fast-cgi per ciascun linguaggio di script.

Lighttpd consuma molta meno memoria. YouTube era un grande utente di lighttpd fino a quando non è stato acquisito da Google. Vai alla sua homepage per maggiori informazioni.

P.S. Nella mia azienda precedente, abbiamo usato entrambi con un bilanciamento del carico per distribuire il traffico http in base ai suoi suffissi URL. Perché non completamente lighttpd? Per motivi legacy.

Answer 4

La risposta dipende dagli obiettivi del tuo progetto. Se sarà un sito su larga scala in cui il tempo di attività è fondamentale e il carico è elevato, vai con lighttpd; si ridimensiona incredibilmente. L'unico aspetto negativo è che devi essere più pratico inizialmente. La maggior parte degli host non lo supporta e vale davvero la pena sapere cosa stai facendo con lighttpd.

Se è un sito per tua madre che attirerà qualche migliaio di visitatori al mese, Apache funzionerà meglio. Sarà in grado di spostarsi su un nuovo host molto più facilmente e il supporto è più facile da trovare.

Answer 5

Utilizza un web server standard. Apache è utilizzato dal 50% dei siti Web ( Netcraft ) , quindi, se usi Apache, i browser web, i ragni, i proxy ecc. delle persone sono praticamente garantiti per funzionare con il tuo sito (il suo web server comunque).

Lighthttpd è utilizzato dall'1,5% dei siti Web ( Netcraft ), quindi è molto meno probabile che le persone testino le loro app con esso.

È probabile che qualsiasi differenza di prestazione non abbia importanza nella produzione; un server Apache può probabilmente servire richieste statiche con una larghezza di banda molto più alta di quella che hai, sull'hardware più lento che potresti distribuire in produzione.