concetto di front-proxy apache + lighttpd

Question

Al fine di alleggerire il carico di Apache, le persone spesso suggeriscono di usare lighttpd per pubblicare contenuti statici.

es. http://www.linux.com/feature/51673

In questa configurazione Apache restituisce le richieste di contenuto statico a lighttpd tramite mod_proxy, servendo al contempo le richieste dinamiche.

La mia domanda è: in che modo questo riduce il carico sul server? Dato che hai ancora un processo apache generato per ogni richiesta che arriva, in che modo influisce positivamente sul carico? Da quello che posso vedere la dimensione del processo di Apache che inoltra la sua richiesta tramite lighttpd è grande come sarebbe se stesse servendo il file stesso.

Answer 1

Esecuzione di Lighttpd dietro Apache per servire file statici mi sembra sicuramente arduo. Apache deve ancora decomprimere i pacchetti HTTP e analizzare la richiesta attraverso il suo albero di analisi, inviare richieste proxy, quindi Lighttpd deve decomprimere, colpire il filesystem e rispedire i file tramite Apache. Non ho mai sentito nessuno usare una configurazione come questa in produzione.

Quello che vedrai, sono le persone che usano un server web leggero come Nginx come frontend server per servire file statici e proxy URL dinamici su Apache. In alternativa, puoi eseguire Varnish o Squid come frontend di proxy inverso nella cache, in modo che tutti i tuoi file statici ad alto traffico (ad es. immagini, CSS ecc. e qualsiasi pagina dinamica che" disposti a inviare intestazioni compatibili con la cache per) sono esauriti.

Apache può anche essere ottimizzato per servire file statici - così spesso quando sento persone lamentarsi di Apache, in realtà non sanno come configurarlo. Hanno sempre usato prefork MPM (vs. threaded o worker) e hanno tutti i tipi di moduli abilitati (di solito sono in esecuzione dal pacchetto Apache del lavello della cucina di una distribuzione Linux che costruisce tutto come moduli e di default per abilitare 10-20 moduli o più). Ottimizza Apache disattivando i moduli non necessari / funzioni stupide come il supporto per .htaccess (che fa sì che Apache esegua la scansione del filesystem su ogni richiesta!) Per primo. (Puoi anche eseguire due istanze di Apache, con un Apache "leggero" come frontend che inoltra un Apache "pesante" per richieste dinamiche ... forse il tuo frontend è threadato ma il tuo backend è prefork perché devi eseguire thread -un moduli esterni non sicuri come mod_php.)

Re:

  

Dato che hai ancora un processo apache   generato per ogni richiesta che arriva   in che modo questo ha un impatto positivo   il carico? Da quello che posso vedere la dimensione   del processo Apache che ne procede il proxy   la richiesta tramite lighttpd è grande   come sarebbe se fosse al servizio del   file stesso.

Se stai generando processi su ogni richiesta, significa che stai usando il prefork MPM. Tenere presente che quando il sistema operativo segnala l'utilizzo della memoria per ciascuno di questi processi, non tutta la memoria è cablata, molti di questi processi sono inattivi. E quando parli di velocità, ti preoccupi più dell'analisi delle richieste e dei rami di codice interno per una determinata richiesta (quanta elaborazione sta facendo il server?) Che dell'utilizzo della memoria segnalato dal sistema operativo.

Ad esempio, se abiliti qualcosa come mod_php, ognuno di questi processi di lavoro salirà all'istante di circa 20-40 M (a seconda di ciò che è abilitato nell'interprete PHP), ma ciò non significa che Apache stia usando quella memoria su richieste statiche. Ovviamente se stai ottimizzando il tuo server per la massima concorrenza su piccoli file statici, abilitare mod_php sarebbe comunque molto male, non sarai in grado di adattare quasi tutti i processi di prefork nella RAM.

Probabilmente potrei trovare una "configurazione da incubo" per Apache che renderebbe effettivamente più lento il servizio di file statici rispetto al proxy di tali richieste a un Lighttpd back-end, ma implicherebbe l'abilitazione di costose funzionalità come .htaccess in Apache disabilitate in Lighttpd, quindi non lo farebbe sii davvero onesto.

Answer 2

1. Se hai ancora il potere di servire contenuti statici e dinamici dalla stessa macchina (come nel tuo articolo di riferimento do), quindi non vedo davvero alcun punto in quella configurazione.
2. Forse riduce il carico di Apache, perché non deve fare IO sul disco, ma aumenterà il carico di Lighttpd su lo stesso computer e riducendo così caricamento disponibile in apache ...
3. Forse l'accesso Lighttpd IO è più leggero di quello di Apache 1.3, ma perché non passare completamente ad Apache 2 o Lighttpd? E se le prestazioni iniziano davvero a risucchiare, ospitare i file statici su un altro computer (media.tuodominio.com).

Una piccola introduzione a come è possibile effettuare una configurazione performante si trova qui: Distribuzione di Django - > scorrere fino a Ridimensionamento alcune pagine prima della fine

Answer 3

Non so molto sul funzionamento interno di Apache, ma una spiegazione che ho visto riguarda la pressione della memoria. In breve, Apache tenta di bilanciare la memoria utilizzata per la memorizzazione nella cache e per le pagine dinamiche; ma di solito finisce con troppa cache e troppo poco per le app. Se li separi in processi diversi, ognuno ottimizzerà per il tipo di carico.

Attualmente, quello che sto facendo è usare nginx come front-end. È veramente veloce e leggero, e specificamente progettato come proxy frontend; ma serve anche file statici. Infatti, poiché può anche chiamare processi FastCGI, è possibile sbarazzarsi di Apache e ottenere comunque i vantaggi dei processi suddivisi file / app. (e c'è qualche extra magia memcached che sembra assolutamente geniale)

(Sì, lighttpd può anche essere usato come frontend per Apache e / o FastCGI)

Answer 4

Non hai un processo Apache generato per ogni richiesta - i file statici (immagini e simili) vengono recuperati direttamente da lighttpd.

Answer 5

Usa Apache MPM Worker fastcgi per ridurre l'utilizzo della memoria del server. Il lavoratore MPM offre contenuti statici meglio di Prefork ed è quasi alla pari con lighttpd quando si tratta di contenuti statici.