proxy inverso nginx, quando utilizzare cache vs store?


8

Sto ristrutturando lo stack web del mio progetto in: nginx -> haproxy -> molte istanze (apache / passeggeri)

Alcuni degli obiettivi includono:

  • posizione singola per la memorizzazione nella cache delle pagine (attualmente eseguita tramite rotaie su ogni macchina apache)
  • contenuto statico più veloce
  • rimuovere ssl dalla pipeline interna
  • registrazione ip (precedentemente persa a causa dell'esecuzione di haproxy in modalità tcp)

Le risorse immagine / foglio di stile / javascript sono memorizzate nella cache, con intestazioni appropriate. La cache della nostra pagina si basa su parametri interni e non dovrebbe rispondere ai controlli di cache tipici. Per raggiungere questi obiettivi, la nostra configurazione è simile

server {

    ...

    location /really_slow_dynamic_content/ {
        root /var/www/tmp;
        error_page 404 = @fetch;
    }

    location @fetch {
        internal;
        proxy_pass   haproxy_ip;
        proxy_store  /var/www/tmp${uri}_cache.html;
        proxy_store_access  user:rw  group:rw  all:r;
    }

    location /assets/ {
        proxy_pass   haproxy_ip;
        proxy_cache  assets;
    }

    location / {
        proxy_pass   haproxy_ip;
    }
}

Non sono molto un amministratore di sistema e so che ci sono molte alternative / modifiche / aggiunte che potrebbero essere utili. Inoltre non capisco bene la differenza tra proxy_cache e proxy_store. Quindi alla mia vera domanda ...

Fino a quando non trasferiamo le risorse sulla macchina nginx, ha senso utilizzare proxy_cache per le risorse e proxy_store per contenuti dinamici lenti?

Inoltre, se ci sono altre considerazioni o software che dovrei prendere in considerazione, mi piacerebbe sentirne parlare. Grazie!


Da quando ho pubblicato questa domanda, mi sono reso conto che la configurazione iniziale che ho usato non usa affatto il negozio e che la pagina di errore e le impostazioni interne dell'esempio wiki ufficiale (semi?) Non erano esattamente opzionali (configurazione aggiornata qui da sembra funzionare e una configurazione funzionante sembra un'eredità migliore per questa domanda). Quindi, usare l'archivio per creare pagine intere lente (e raramente aggiornate) e la cache effettiva per immagini, javascript e simili sembra funzionare abbastanza bene per noi. Accetterò l'unica risposta, dato che almeno mi ha dato un indizio per rintracciare il mio problema, ma non ho ancora la sensazione se sto usando le due direttive nel modo in cui erano destinate oppure no (beh, almeno non per quanto riguarda l'archivio, la cache sembra un po 'più ovvia).


Ai fini dell'eredità, questa discussione mi è stata molto utile quando ho affrontato questi problemi. ruby-forum.com/topic/140396
Chris

Risposte:


3

Se la memoria mi serve correttamente, proxy_store memorizza una rappresentazione binaria di una richiesta per un elemento mentre proxy_cache memorizza una copia cache dell'articolo nel suo formato di base.

proxy_cache è in realtà un motore di cache appropriato con più livelli ed è adatto per archiviare contenuti da più siti usando le stesse chiavi.

Personalmente utilizzo proxy_cache per archiviare oltre 2 miliardi di immagini di prodotti su ciascuno dei nostri server di contenuti statici.


1

proxy_store viene utilizzato per creare un mirror di oggetti "su richiesta". Mette gli oggetti nello stesso percorso in cui esiste l'oggetto dato sul back-end.

Nel caso di contenuto dinamico lento, proxy_cache è più appropriato, poiché supporta la scadenza della cache.

Un esempio di dove proxy_store è più utile potrebbe essere un mirror di file rpm in cui non sarà mai necessario scadere un nome file / versione .

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.