Sto pensando all'architettura per un nuovo server web. Avere Varnish come cache davanti a Nginx come proxy inverso e servire file statici davanti ad Apache per tutti i lavori pesanti sarebbe una buona idea?
Ho intenzione di eseguire php e ruby su applicazioni rotaie.
Ci saranno troppe spese generali che passano richieste php per apache attraverso altri due processi?
Molte grazie!
Risposte:
Sì, è valido Il mio approccio personale sarebbe usare Varnish in anticipo e usare VCL per dividere il traffico tra richieste NGINX statiche e il tuo sollevamento pesante (che sia Apache o Passeggero o ... non importa). Ciò è particolarmente vero se si trova sulla stessa macchina in quanto non è necessario l'overhead aggiuntivo. Non ti compra necessariamente nulla.
Varnish non supporta (ancora) la compressione gzip, quindi potrebbe essere un'idea scambiarlo con nginx davanti per comprimere ciò che la vernice rimanda. Poiché varnish e nginx non combattono per le stesse risorse (nginx utilizza la CPU per la compressione gzip, mentre varnish utilizza la memoria) dovrebbero funzionare senza problemi sulla stessa macchina.
Varnish ora supporta la compressione gzip , quindi a meno che tu non abbia bisogno della terminazione SSL (come suggerito nei commenti), suggerirei di mettere la vernice direttamente in contatto con Internet.
Per http:
(internet) -> (vernice, gzip, cache, esi) -> (applicazione)
Per https:
(internet) -> (nginx, ssl) -> (vernice, gzip, cache, esi) -> (applicazione)
Se vuoi anche l'apache (per l'onnipresente supporto mod_foobar), lo metterei tra vernice e l'applicazione
Aggiornamento: aggiornato per includere il supporto gzip in vernice 3.0. Aggiunto ssl / esi come suggerito nei commenti
La quantità di spese generali non dovrebbe essere significativa. Sto assumendo parte del motivo per cui si desidera avere questi due livelli è per la scalabilità; nel qual caso molto probabilmente vedresti, rispetto all'apache, che vernice e nginx non stanno lavorando molto duramente.
Se tutti e tre i livelli su un computer, si dovrebbe avere un impatto minore sulle prestazioni prima di raggiungere la capacità del server stesso.
In alternativa, perché non verniciare + nginx con passeggero? Ho usato questa configurazione in passato e nginx usando il passeggero è relativamente leggero e ha funzionato abbastanza bene. Potrebbe valere la pena pensarci se non sei sposato con Apache che esegue il tuo stack di binari.
Sono l'amministratore di sistema per una piattaforma di e-commerce di avvio. Usiamo la vernice + nginx davanti al nostro stack PHP / apache e ha funzionato a meraviglia.
Abbiamo un'applicazione ad alto consumo di memoria e l'app utilizzava circa 15-20 grammi di RAM per nodo web e una volta che abbiamo messo la vernice davanti è ora circa 8 grammi di RAM per nodo. Non hanno mai avuto un picco.
Quindi lo consiglio vivamente.
Sto eseguendo Drupal, con il modulo boost su un server Apache + PHP + MySQL, ma davanti a loro sto usando Nginx con la funzione gzip-static attiva e usando i risultati di boost per servire gli utenti.
E soprattutto sto usando la vernice, tutto sullo stesso PC, sto ottenendo buoni risultati.
Sto anche usando Nginx per modificare le intestazioni che Drupal non fa molto bene per la cache.
Non è una buona idea se non hai bisogno di qualcosa come ESI. Nginx ha il proprio sistema di memorizzazione nella cache che offre prestazioni migliori .
Apache può essere utilizzato per terminare SSL (decrittografare), controllare http://noosfero.org/Development/Varnish#SSL