Vernice contro altri proxy inversi

Sto lavorando con un'organizzazione che ha distribuito Varnish come proxy inverso nella cache per tutto il loro traffico web. Il loro traffico è costituito da molti siti Web dinamici generati dai clienti, con la solita raccolta di risorse statiche sospese di lato.

Mentre sto provando ad apprezzare la vernice (penso che abbia un'architettura abbastanza buona, in linea di principio), sto avendo qualche problema a gestirla e risolvere i problemi quando si presentano, quindi mi chiedo se è davvero la scelta giusta. Ho usato calamari in passato come proxy inverso, ma non nello stesso tipo di ruolo, quindi non ho una base chiara per il confronto.

La mia domanda è rivolta alle persone che hanno schierato la vernice in produzione o l'hanno valutata seriamente rispetto alle alternative: hai aderito alla vernice o hai finito con un altro proxy inverso? Quali sono stati i tuoi punti chiave per rimanere con esso o cambiare, e se hai usato qualcos'altro, cosa hai finito per usare?

Bene, sto usando Varnish sui miei server web, principalmente per motivi di prestazioni, anche se le sue funzionalità di bilanciamento del carico sono utili.

Il mio caso d'uso è la memorizzazione nella cache di fronte ai siti Web basati su Django e fa miracoli per le prestazioni di caricamento della pagina. Sono in grado di servire la maggior parte delle pagine direttamente dalla cache e gestire un flusso di visitatori con pochi problemi.

Il motivo per cui ho scelto Varnish era principalmente prestazioni / scalabilità. I punti principali:

• Varnish consente al kernel di gestire la memoria virtuale, dove Squid tenta di mantenere cache del disco e della memoria separate, può portare al kernel e Squid a litigare un po 'su ciò che deve essere eseguito il paging su disco.
• Varnish usa VCL, è il suo linguaggio di configurazione specifico del dominio, che si compila fino al codice macchina tramite C. Questo è un vantaggio molto reale se hai un po 'più di logica nella tua configurazione - stripping condizionale dell'intestazione ecc.

Nella mia esperienza, Varnish si comporta un po 'meglio del calamaro nella maggior parte dei casi e molto meglio sui picchi di traffico. D'altra parte, la configurazione corretta di Varnish richiederà un po 'di traino della mailing list, dal momento che non ci sono così tanti documenti pronti per l'uso specifici per la rete che circolano in rete come ci sono per Squid - principalmente a causa del fatto che Varnish è un progetto abbastanza giovane a confronto.

Ho passato molto tempo a cercare di rendere Varnish 1.x stabile su hardware linux / dell standard bog, si sarebbe sempre bloccato in qualche modo strano e il suo cane da guardia l'avrebbe riavviato. Il che andava bene, tranne per la cache conquistata duramente che non era stata perseverata altrove ...

Detto questo, stai davvero usando lo strumento giusto per il lavoro? Se si desidera un proxy inverso che memorizzerà nella cache i risultati della richiesta (supponendo che si stiano fornendo intestazioni della cache di buona qualità), la vernice è una buona opzione. Spero che sia diventato più stabile nella versione 2.0

Tuttavia, se si esegue un sito * onRails e si desidera il bilanciamento del carico su più server back-end, HAProxy o Nginx potrebbero essere la strada da percorrere. Se non hai bisogno di una logica url complicata (reindirizzamenti, corrispondenze regex per riscrivere gli URL più vecchi, ecc.) HAProxy si adatterà al conto. Se hai bisogno di qualcosa di più capace, allora prova Nginx.