Ho un sistema con nginx / php-fpm / varnish / wordpress e amazon s3.

Ora ho esaminato molti file di configurazione durante l'installazione del sistema e in tutti ho trovato qualcosa del genere:

    /* If the request is for pictures, javascript, css, etc */
    if (req.url ~ "\.(jpg|jpeg|png|gif|css|js)$") {
        /* Remove the cookie and make the request static */
        unset req.http.cookie;
        return (lookup);
    }

Non capisco perché questo sia fatto. La maggior parte degli esempi esegue anche NginX come server Web. Ora la domanda è: perché dovresti usare la cache varnish per memorizzare nella cache questi file statici.

Per me ha molto più senso memorizzare nella cache solo i file dinamici in modo che php-fpm / mysql non venga colpito così tanto.

Ho ragione o mi sto perdendo qualcosa qui?

AGGIORNARE

Voglio aggiungere alcune informazioni alla domanda in base alla risposta fornita.

Se si dispone di un sito Web dinamico, in cui i contenuti cambiano molto, il logorio non ha senso. Ma se si utilizza WordPress per un sito Web statico, ad esempio, questo può essere memorizzato nella cache per lunghi periodi di tempo.

Detto questo, più importante per me è il principio statico . Ho trovato un collegamento con alcuni test e benchmark su diverse app cache e server web.

http://nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-varnish-vs-gwan/

NginX è in realtà più veloce nell'ottenere il tuo contenuto statico, quindi ha più senso lasciarlo passare. NginX funziona alla grande con i file statici.

-

A parte questo, il più delle volte il contenuto statico non è nemmeno nel server web stesso. Il più delle volte questo contenuto viene archiviato su un CDN da qualche parte, forse AWS S3, qualcosa del genere. Penso che la cache di vernice sia l'ultimo posto dove vuoi avere il tuo contenuto statico memorizzato.

Ci sono alcuni vantaggi di Varnish. Il primo che noti sta riducendo il carico su un server back-end. In genere, memorizza nella cache il contenuto che viene generato in modo dinamico ma cambia raramente (rispetto alla frequenza con cui si accede). Prendendo il tuo esempio Wordpress, la maggior parte delle pagine presumibilmente non cambia molto spesso, e ci sono alcuni plugin che esistono per invalidare una cache di vernice quando la pagina cambia (ad es. Nuovo post, modifica, commento, ecc.). Pertanto, si memorizza nella cache a tempo indeterminato e si invalida al momento della modifica, il che comporta il carico minimo sul server back-end.

Nonostante l'articolo collegato, la maggior parte delle persone suggerirebbe che Varnish funzioni meglio di Nginx se configurato correttamente - sebbene, (e odio davvero ammetterlo) - i miei test sembrano concordare sul fatto che nginx può servire un file statico più veloce della vernice ( fortunatamente, non uso la vernice per quello scopo). Penso che il problema sia che se finisci con Varnish, hai aggiunto un ulteriore livello alla tua configurazione. Passare attraverso quel livello aggiuntivo al server back-end sarà sempre più lento della semplice pubblicazione diretta dal back-end - ed è per questo che consentire a Varnish di memorizzare nella cache potrebbe essere più veloce - si risparmia un passaggio. L'altro vantaggio è sul fronte disk-io. Se imposti la vernice per usare malloc, non colpisci affatto il disco, il che lo rende disponibile per altri processi (e di solito accelererebbe le cose).

Penso che sarebbe necessario un benchmark migliore per misurare realmente le prestazioni. La richiesta ripetuta dello stesso file singolo attiva le cache del file system che iniziano a spostare l'attenzione dai server Web stessi. Un benchmark migliore userebbe l'assedio con alcune migliaia di file statici casuali (possibilmente anche dai registri del server) per simulare un traffico realistico. Probabilmente, come hai detto, è diventato sempre più comune scaricare il contenuto statico su una CDN, il che significa che Varnish probabilmente non lo servirà all'inizio (menzionate S3).

In uno scenario del mondo reale, è probabile che si dia la priorità all'utilizzo della memoria, in primo luogo il contenuto dinamico, poiché è il più costoso da generare; quindi piccoli contenuti statici (ad es. js / css) e infine immagini - probabilmente non memorizzeresti nella cache altri media in memoria, a meno che tu non abbia davvero un buon motivo per farlo. In questo caso, con Varnish che carica i file dalla memoria e che nginx li carica dal disco, Varnish probabilmente supererà le prestazioni di nginx (si noti che le cache di nginx sono solo per proxy e fastCGI, e quelle, per impostazione predefinita, sono basate su disco - anche se è possibile usare nginx con memcached).

(Il mio rapido - molto approssimativo, per non dare alcuna credibilità - il test ha mostrato che nginx (diretto) era il più veloce - chiamiamolo 100%, la vernice (con malloc) era un po 'più lenta (circa 150%) e nginx dietro la vernice ( con pass) è stato il più lento (circa il 250%). Parla da solo - tutto o niente - aggiungendo il tempo extra (e l'elaborazione) per comunicare con il backend, suggerisce semplicemente che se stai usando Varnish e hai la RAM da risparmiare , potresti anche solo memorizzare nella cache tutto ciò che puoi e servirlo da Varnish invece di tornare a nginx.)

Penso che potresti perdere qualcosa.

Per definizione, i file dinamici cambiano. In genere, cambiano eseguendo una sorta di query del database che influisce sul contenuto della pagina che viene offerto all'utente. Pertanto, non si desidera memorizzare nella cache il contenuto dinamico. Se lo fai, diventa semplicemente contenuto statico e molto probabilmente contenuto statico con contenuto errato.

Ad esempio, supponiamo di avere una pagina con il nome utente dell'utente registrato nella parte superiore della pagina. Ogni volta che la pagina viene caricata, viene eseguita una query del database per determinare quale nome utente appartiene all'utente che ha effettuato l'accesso e ha richiesto la pagina per garantire che venga visualizzato il nome corretto. Se dovessi memorizzare nella cache questa pagina, la query del database non avverrebbe e tutti gli utenti vedrebbero lo stesso nome utente nella parte superiore della pagina e probabilmente non sarà il loro nome utente. È necessario che la query si verifichi ad ogni caricamento della pagina per garantire che a ogni utente venga visualizzato il nome utente corretto. Pertanto non è memorizzabile nella cache.

Estendi quella logica a qualcosa di un po 'più problematico come le autorizzazioni utente e puoi capire perché il contenuto dinamico non dovrebbe essere memorizzato nella cache. Se il database non viene colpito per il contenuto dinamico, il server di amministrazione centrale non ha modo di determinare se l'utente che richiede la pagina dispone delle autorizzazioni per visualizzare quella pagina.

Il contenuto statico è, per definizione, uguale per tutti gli utenti. Pertanto non è necessario eseguire alcuna query sul database per personalizzare quella pagina per ciascun utente, pertanto è logico memorizzarlo nella cache per eliminare le query del database inutili. Le immagini sono un ottimo esempio di contenuto statico: vuoi che tutti gli utenti vedano la stessa immagine di intestazione, gli stessi pulsanti di accesso, ecc., Quindi sono candidati eccellenti per la memorizzazione nella cache.

Nel frammento di codice sopra riportato vedrai un frammento di VCL Varnish molto tipico che forza la memorizzazione nella cache di immagini, CSS e JavaScript. Per impostazione predefinita, Varnish non memorizzerà nella cache alcuna richiesta contenente un cookie. La logica è che se nella richiesta è presente un cookie, ci deve essere qualche motivo per cui il server ha bisogno di quel cookie, quindi è richiesto sul back-end e deve essere passato attraverso la cache. In realtà, molti CMS (Drupal, Wordpress, ecc.) Collegano i cookie a quasi tutto ciò che è necessario o meno, quindi è comune scrivere VCL per rimuovere i cookie dal contenuto che è noto per essere statico che a sua volta provoca la memorizzazione nella cache di Varnish esso.

Ha senso?

Per i contenuti dinamici , alcuni tipi come le quotazioni di borsa cambiano spesso (aggiornate ogni secondo SaaS serverda a a backend server) ma potrebbero essere interrogate ancora più spesso (da decine di migliaia di subscription clients):

[stock calculation / backend server] ----- [SaaS server] ------ [subscription clients]

In questo caso, la memorizzazione nella cacheSaaS server dell'aggiornamento al secondo da backend serversconsente di soddisfare le query di decine di migliaia di subscription users.

Senza una cache sul server SaaS, questo modello non funzionerebbe.

La memorizzazione nella cache di file statici con Varnish trarrebbe vantaggio in termini di offload di Nginx. Naturalmente, se hai molti file statici da memorizzare nella cache, sprecherai la RAM. Tuttavia, Varnish ha una bella funzionalità: supporta più back-end di archiviazione per la sua cache.

Per file statici: cache su HDD Per tutto il resto: cache su RAM.

Questo dovrebbe darti maggiori informazioni su come implementare questo scenario: http://www.getpagespeed.com/server-setup/varnish-static-files-cache