In che modo nginx e memcached lavorano insieme?

Abbiamo un'applicazione Web basata su Java EE in esecuzione su un cluster di server di app Glassfish . Il traffico in entrata sarà principalmente richieste RESTful per rappresentazioni basate su XML delle risorse delle nostre applicazioni, ma forse il 5% del traffico potrebbe essere per rappresentazioni basate su JSON o XHTML / CSS.

Stiamo ora esaminando le soluzioni di bilanciamento del carico per distribuire il traffico in entrata attraverso le istanze Glassfish nel cluster. Stiamo anche esaminando come scaricare il cluster usando memcached, una mappa hash distribuita in memoria le cui chiavi sarebbero i nomi delle risorse REST (ad es. "/ User / bob", "/ group / jazzlovers") e i cui valori sono le rappresentazioni XML corrispondenti.

Un approccio che sembra promettente è quello di uccidere entrambi gli uccelli con una fava e utilizzare il server HTTP nginx / proxy inverso leggero e veloce . Nginx gestirà ogni richiesta in arrivo cercando prima il suo URI in memcached per vedere se c'è già una rappresentazione XML non scaduta. In caso contrario, nginx invia la richiesta a una delle istanze di Glassfish. Il modulo memginato nginx è descritto in questo breve articolo scritto .

Qual è la tua impressione generale con nginx e memcached utilizzata in questo modo, quanto sei felice con loro? Quali risorse hai trovato più utili per conoscerli? Se le hai provate e non si adattavano ai tuoi scopi, perché no, e cosa hai usato invece?

Nota: ecco una domanda correlata . Prima di conoscere ServerFault l'ho chiesto su StackOverflow .

Modifica: tutte le risposte qui finora sono state molto utili, sebbene non ci sia stata esperienza diretta. Questa risposta alla fine è apparsa su StackOverflow ed è stata piuttosto rialzista sulla configurazione di nginx / memcached.

Dovresti davvero usare un server cache di fronte ai tuoi server web. Raccomando Varnish-cache. Lo usiamo al lavoro con il sito Web più grande e più frequentato della Scandinavia. Abbiamo sostituito 13 scatole di calamari altamente caricate con 1 scatola di vernice e 1 di riserva.

Ho confrontato una semplice app sul mio sito Web privato ed è passata da 9 richieste al secondo a oltre 2000.

Decidi tu per quanto tempo conserva le cose in memoria, puoi fare fino alla fine dei tempi e quindi inviare una richiesta di eliminazione http al server cache quando i dati cambiano.

La mia opinione personale, per esperienza, è che se si utilizza un bilanciamento del carico, si desidera limitare completamente quella casella alle funzioni di bilanciamento del carico. Avere il bilanciamento del carico che serve il contenuto, anche da una cache, degrada la funzionalità di bilanciamento del carico in situazioni di carico elevato (più connessioni rimangono attive più a lungo, riducendo capacità e throughput complessivi).

Consiglio di fare in modo che l'app esegua la ricerca e offra il contenuto memorizzato nella cache e consenta al bilanciamento del carico di eseguire il proprio lavoro. Detto questo, nginx non è perfetto quando si tratta di bilanciamento del carico: offre solo un algoritmo round robin di base. Consiglierei invece haproxy. Se hai bisogno di servizi di decrittazione SSL in anticipo, nginx funziona bene di fronte a haproxy, nella mia esperienza.

Penso che andrai a un punto morto nel caso in cui avessi bisogno di cose come il bilanciamento del carico, l'alta disponibilità e così via.

Inoltre, considera tale situazione: quando l'utente è autenticato la pagina ha un aspetto diverso, con funzionalità aggiuntive disponibili e personalizzate per ogni utente. Gli URL sono gli stessi per la comodità del collegamento e così via. Ad esempio, il sito in cui l'utente autorizzato non deve inserire il proprio nome / captcha per i commenti o il sito visualizza il nome utente in alto, quando si accede (come serverfault). In tali casi, nginx sarà inutilizzabile, poiché non è possibile distinguere l'utente autorizzato da non autenticato.

Se non hai bisogno di SSL, ti suggerirei di eseguire Varnish. È stato progettato come HTTP Accelerator, non come web server o proxy. Se hai bisogno di SSL, esegui nginx come acceleratore SSL e vernicia come semplice acceleratore HTTP, perché Varnish non può gestire SSL.

Penso che la scelta del server di memorizzazione nella cache sia specifica dell'applicazione e non è possibile fare commenti generalizzati a riguardo senza un'approfondita analisi dell'app.

la mia scelta è haproxy. Proxy inverso molto piccolo e molto veloce, ma non è proxy cache! Uso per il mio sistema di cache "Squid Web Proxy"

CACHE /squid/ -> Load-balancing /Haproxy/ -> WEB I /lighttpd/
                                          -> WEB II /lighttpd/
                                          -> WEB III /lighttpd/

Questo lavoro è perfetto per il mio sistema web