Nginx reverse proxy, quand utiliser cache vs store?

Je suis en train de restructurer la pile Web de mon projet pour: nginx -> haproxy -> plusieurs instances (apache / rails de passagers)

Certains des objectifs comprennent:

• emplacement unique pour la mise en cache des pages (actuellement effectué via des rails sur chaque machine Apache)
• contenu statique plus rapide
• supprimer ssl du pipeline interne
• journalisation IP (précédemment perdue en raison de l'exécution de haproxy en mode tcp)

Les actifs image / feuille de style / javascript sont mis en cache, avec des en-têtes appropriés. Notre mise en cache de page est basée sur des paramètres internes et ne devrait pas répondre aux contrôles de cache typiques. Pour atteindre ces objectifs, notre configuration ressemble à quelque chose

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;
    }
}

Je ne suis pas vraiment un administrateur système, et je sais qu'il existe de nombreuses alternatives / ajustements / ajouts qui pourraient être utiles. Je ne comprends pas non plus très bien la différence entre proxy_cache et proxy_store. Donc à ma vraie question ...

Jusqu'à ce que nous déplacions les actifs vers la machine nginx, est-il judicieux d'utiliser proxy_cache pour les actifs et proxy_store pour le contenu dynamique lent?

De plus, s'il y a d'autres considérations ou logiciels que je devrais envisager, j'aimerais en entendre parler. Je vous remercie!

Depuis la publication de cette question, j'ai réalisé que la configuration initiale que j'utilisais n'utilisait pas du tout la boutique, et que la page d'erreur et les paramètres internes de l' exemple wiki (semi?) Officiel n'étaient pas exactement facultatifs (la configuration a été mise à jour ici depuis cela semble fonctionner, et une configuration de travail semble être un meilleur héritage pour cette question). Donc, utiliser le magasin pour créer des pages complètes lentes (et rarement mises à jour), et le cache réel pour les images, javascript et autres semble fonctionner assez bien pour nous. J'accepterai la seule réponse, car cela m'a au moins permis de suivre mon problème, mais je ne sais toujours pas si j'utilise ou non les deux directives d'une manière à laquelle elles étaient destinées ou pas (enfin, du moins pas en ce qui concerne le magasin, le cache semble un peu plus évident).

Si la mémoire me sert correctement, proxy_store stocke une représentation binaire d'une demande pour un élément tandis que proxy_cache stocke une copie mise en cache de l'élément sous sa forme de base.

proxy_cache est en fait un moteur de mise en cache approprié avec plusieurs niveaux et convient au stockage de contenu de plusieurs sites à l'aide des mêmes clés.

J'utilise personnellement proxy_cache pour stocker plus de 2 milliards d'images de produits sur chacun de nos serveurs de contenu statique.

proxy_store est utilisé pour créer un miroir d'objets «à la demande». Il place les éléments dans le même chemin que l'élément donné existe sur le backend.

Dans le cas d'un contenu dynamique lent, proxy_cache est plus approprié, car il prend en charge l'expiration du cache.

Un exemple où proxy_store est plus utile pourrait être un miroir de fichiers rpm où un nom de fichier / version n'aura jamais besoin d'être expiré .