J'ai un système exécutant nginx / php-fpm / vernis / wordpress et amazon s3.

Maintenant, j'ai regardé beaucoup de fichiers de configuration lors de la configuration du système, et dans chacun d'eux, j'ai trouvé quelque chose comme ceci:

    /* 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);
    }

Je ne comprends pas pourquoi cela se fait. La plupart des exemples exécutent également NginX en tant que serveur Web. Maintenant, la question est de savoir pourquoi utiliseriez-vous le cache de vernis pour mettre en cache ces fichiers statiques.

Il est beaucoup plus logique pour moi de ne mettre en cache que les fichiers dynamiques afin que php-fpm / mysql ne soit pas autant touché.

Ai-je raison ou manque-t-il quelque chose ici?

MISE À JOUR

Je veux ajouter quelques informations à la question en fonction de la réponse donnée.

Si vous avez un site Web dynamique, où le contenu change beaucoup, le chaching n'a pas de sens. Mais si vous utilisez WordPress pour un site Web statique par exemple, cela peut être mis en cache pendant de longues périodes.

Cela dit, le plus important pour moi est le contenu statique . J'ai trouvé un lien avec des tests et des tests de performances sur différentes applications de cache et applications de serveur Web.

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

NginX est en fait plus rapide pour obtenir votre contenu statique, il est donc plus logique de le laisser passer. NginX fonctionne très bien avec les fichiers statiques.

-

En dehors de cela, la plupart du temps, le contenu statique n'est même pas dans le serveur Web lui-même. La plupart du temps, ce contenu est stocké sur un CDN quelque part, peut-être AWS S3, quelque chose comme ça. Je pense que le cache de vernis est le dernier endroit où vous voulez avoir votre contenu statique stocké.

Le vernis présente quelques avantages. Le premier que vous notez réduit la charge sur un serveur principal. En général, en mettant en cache du contenu généré dynamiquement mais qui change rarement (par rapport à la fréquence à laquelle il est consulté). En prenant votre exemple Wordpress, la plupart des pages ne changent probablement pas très souvent, et il existe des plugins qui invalident un cache de vernis lorsque la page change (c.-à-d. Nouveau message, modification, commentaire, etc.). Par conséquent, vous mettez en cache indéfiniment et invalidez le changement - ce qui entraîne la charge minimale sur votre serveur principal.

Nonobstant l'article lié, la plupart des gens suggèrent que Varnish fonctionne mieux que Nginx s'il est correctement configuré - bien que (et je déteste vraiment l'admettre) - mes propres tests semblent confirmer que nginx peut servir un fichier statique plus rapidement que le vernis ( heureusement, je n'utilise pas de vernis à cet effet). Je pense que le problème est que si vous finissez par utiliser Varnish, vous avez ajouté une couche supplémentaire à votre configuration. Passer cette couche supplémentaire au serveur principal sera toujours plus lent que de simplement servir directement depuis le serveur principal - et c'est pourquoi permettre à Varnish de mettre en cache peut être plus rapide - vous économisez une étape. L'autre avantage est sur le disque-io. Si vous configurez le vernis pour utiliser malloc, vous ne frappez pas du tout sur le disque, ce qui le laisse disponible pour d'autres processus (et accélère généralement les choses).

Je pense que l'on aurait besoin d'une meilleure référence pour vraiment évaluer la performance. La demande répétée du même fichier unique déclenche des caches de système de fichiers qui commencent à détourner l'attention des serveurs Web eux-mêmes. Un meilleur benchmark utiliserait le siège avec quelques milliers de fichiers statiques aléatoires (peut-être même à partir des journaux de votre serveur) pour simuler un trafic réaliste. On peut dire que, comme vous l'avez mentionné, il est devenu de plus en plus courant de décharger du contenu statique vers un CDN, ce qui signifie que Varnish ne le servira probablement pas pour commencer (vous mentionnez S3).

Dans un scénario réel, vous prioriseriez probablement votre utilisation de la mémoire - le contenu dynamique d'abord, car il est le plus cher à générer; puis un petit contenu statique (par exemple js / css), et enfin des images - vous ne mettriez probablement pas en cache d'autres médias en mémoire, sauf si vous avez une très bonne raison de le faire. Dans ce cas, avec Varnish chargeant des fichiers à partir de la mémoire et nginx les chargeant à partir du disque, Varnish surpassera probablement nginx (notez que les caches de nginx sont uniquement pour le proxy et fastCGI, et ceux, par défaut, sont basés sur le disque - bien qu'il soit possible d'utiliser nginx avec memcached).

(Mon rapide - très rugueux, pour ne pas être crédible - le test a montré que nginx (direct) était le plus rapide - appelons-le 100%, le vernis (avec malloc) était un peu plus lent (environ 150%), et nginx derrière le vernis ( avec passe) était le plus lent (environ 250%). Cela parle de lui-même - tout ou rien - l'ajout de temps supplémentaire (et de traitement) pour communiquer avec le backend, suggère simplement que si vous utilisez Varnish et que vous avez la RAM à revendre , vous pourriez tout aussi bien mettre en cache tout ce que vous pouvez et le servir à partir de Varnish au lieu de le renvoyer à nginx.)

Je pense que vous manquez peut-être quelque chose.

Par définition, les fichiers dynamiques changent. En règle générale, ils changent en effectuant une sorte de requête de base de données qui affecte le contenu de la page servie à l'utilisateur. Par conséquent, vous ne souhaitez pas mettre en cache le contenu dynamique. Si vous le faites, cela devient simplement du contenu statique et très probablement du contenu statique avec un contenu incorrect.

À titre d'exemple simple, supposons que vous ayez une page avec le nom d'utilisateur de l'utilisateur connecté en haut de la page. Chaque fois que cette page est chargée, une requête de base de données est exécutée pour déterminer quel nom d'utilisateur appartient à l'utilisateur connecté qui demande la page, ce qui garantit que le nom correct est affiché. Si vous mettiez en cache cette page, la requête de base de données ne se produirait pas et tous les utilisateurs verraient le même nom d'utilisateur en haut de la page et ce ne serait probablement pas leur nom d'utilisateur. Vous devez que cette requête se produise à chaque chargement de page pour garantir que le nom d'utilisateur approprié est affiché pour chaque utilisateur. Il n'est donc pas mis en cache.

Étendez cette logique à quelque chose d'un peu plus problématique comme les autorisations utilisateur et vous pouvez voir pourquoi le contenu dynamique ne doit pas être mis en cache. Si la base de données n'est pas atteinte pour le contenu dynamique, le CMS n'a aucun moyen de déterminer si l'utilisateur qui demande la page dispose des autorisations pour voir cette page.

Le contenu statique est, par définition, le même pour tous les utilisateurs. Par conséquent, aucune requête de base de données ne doit être effectuée pour personnaliser cette page pour chaque utilisateur, il est donc judicieux de la mettre en cache pour éliminer les requêtes de base de données inutiles. Les images sont un très bon exemple de contenu statique - vous voulez que tous les utilisateurs voient la même image d'en-tête, les mêmes boutons de connexion, etc., ils sont donc d'excellents candidats pour la mise en cache.

Dans votre extrait de code ci-dessus, vous voyez un extrait VCL Varnish très typique qui force les images, css et javascript à être mis en cache. Par défaut, Varnish ne mettra en cache aucune demande contenant un cookie. La logique étant que s'il y a un cookie dans la demande, il doit y avoir une raison pour laquelle le serveur a besoin de ce cookie, il est donc requis sur le serveur principal et doit être transmis via le cache. En réalité, de nombreux CMS (Drupal, Wordpress, etc.) attachent des cookies à presque tout, que cela soit nécessaire ou non. il.

Ça a du sens?

Pour les contenus dynamiques , certains types de cotations boursières changent en fait souvent (mis à jour chaque seconde sur un à SaaS serverpartir de a backend server) mais peuvent être interrogés encore plus souvent (par dizaines de milliers subscription clients):

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

Dans ce cas, la mise en cache sur la SaaS servermise à jour par seconde de backend serverspermet de satisfaire les requêtes de dizaines de milliers de subscription users.

Sans cache sur le serveur SaaS, ce modèle ne fonctionnerait tout simplement pas.

La mise en cache de fichiers statiques avec Varnish bénéficierait en termes de déchargement de Nginx. Bien sûr, si vous avez beaucoup de fichiers statiques à mettre en cache, cela gaspillera de la RAM. Cependant, Varnish a une fonctionnalité intéressante - il prend en charge plusieurs backends de stockage pour son cache.

Pour les fichiers statiques: cache sur disque dur Pour tout le reste: cache sur RAM.

Cela devrait vous donner plus d'informations sur la façon de mettre en œuvre ce scénario: http://www.getpagespeed.com/server-setup/varnish-static-files-cache