Pourquoi cache les fichiers statiques avec vernis, pourquoi ne pas passer
J'ai un système exécutant nginx/php-fpm/vernis/wordpress et Amazon S3.
Maintenant, j'ai examiné beaucoup de fichiers de configuration lors de la configuration du système et 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 est fait. La plupart des exemples exécutent également Nginx comme Web WebServer. Maintenant, la question est de savoir pourquoi utiliseriez-vous le cache de vernis pour mettre en cache ces fichiers statiques.
Cela fait beaucoup plus de sens pour moi de mettre uniquement en cache les fichiers dynamiques de sorte que php-fpm/mysql ne soit pas frappé beaucoup.
Suis-je correct ou je manque quelque chose ici?
METTRE À JOUR
Je souhaite ajouter des informations à la question basée sur la réponse donnée.
Si vous avez un site Web dynamique, où le contenu change effectivement beaucoup, la 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, plus important pour moi est Content statique . J'ai trouvé un lien avec des tests et des points de repère sur différentes applications de cache et des applications WebServer.
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 bien avec des fichiers statiques.
-
En dehors de cela, la plupart du temps statique ne se trouve 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 vous avoir du contenu statique stocké.
Il y a quelques avantages au vernis. Le premier que vous notez consiste à réduire la charge sur un serveur de backend. Typiquement, en mettant en cache le contenu généré de manière dynamique mais change rarement (par rapport à la fréquence à laquelle il est accessible). Prenant votre Wordpress Exemple, la plupart des pages ne changent probablement pas très souvent, et il existe des plugins qui existent pour invalider un cache de vernis lorsque la page change (c'est-à-dire un nouveau poste, Modifier, Commentaire, etc.) . Par conséquent, vous mettez en cache indéfiniment et invalide sur le changement - ce qui entraîne la charge minimale à votre serveur Backend.
L'article lié non-résistants, la plupart des gens suggèrent que le vernis fonctionne mieux que Nginx si la configuration est correctement configurée - bien que, (et je déteste vraiment à l'admettre) - Mes propres tests semblent être d'accord sur ce nginx peuvent servir un fichier statique plus rapidement que le vernis ( Heureusement, je n'utilise pas de vernis à cette fin). Je pense que le problème est que si vous finissez par utiliser de vernis, vous avez ajouté une couche supplémentaire à votre configuration. En passant à travers cette couche supplémentaire au serveur de Backend restera toujours plus lentement que de servir directement à partir du backend - et c'est pourquoi permettre au vernis de cache peut être plus rapide - vous économisez une étape. L'autre avantage est sur le disque de disque-io. Si vous configurez le vernis pour utiliser MALLOC, vous n'allez pas du tout le disque, ce qui la laisse disponible pour d'autres processus (et accélérerait généralement les choses).
Je pense qu'on aurait besoin d'une meilleure référence pour évaluer vraiment la performance. Demandant à plusieurs reprises le même fichier, le fichier unique, déclenche des caches système de fichiers qui commencent à déplacer l'accent sur les serveurs Web eux-mêmes. Un meilleur repère utiliserait Siege avec quelques milliers de fichiers statiques aléatoires (éventuellement à partir de vos journaux de serveur) pour simuler un trafic réaliste. On peut soutenir que, comme vous l'avez mentionné, il est devenu de plus en plus courant de décharger du contenu statique à un CDN, ce qui signifie que le vernis ne le servira probablement pas à commencer (vous mentionnez S3).
Dans un scénario réel, vous préférez prioriser votre utilisation de la mémoire - le contenu dynamique d'abord, car il est le plus cher à générer; Ensuite, petit contenu statique (par exemple JS/CSS) et enfin d'images - vous ne cacheriez probablement pas d'autres médias en mémoire, à moins que vous n'ayez une raison probable de le faire. Dans ce cas, avec des fichiers de chargement de vernis de la mémoire et NGinx les chargeant du disque, le vernis s'effectue probablement de NGinx (Notez que les caches de Nginx ne sont que pour la proxyage et les FastCGI, et celles-ci sont basées sur le disque - bien que ce soit possible d'utiliser nginx avec memcached).
(Mon rapide - très rugueux, à ne pas avoir reçu de crédibilité - test montré 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 - ajouter le temps supplémentaire (et le traitement) pour communiquer avec le backend, suggère simplement que si vous utilisez du vernis et que vous utilisez le RAM Pour épargner, vous pourriez aussi bien vous cacher tout ce que vous pouvez et le servir de vernis au lieu de passer à Nginx.)
Je pense que vous serez peut-être manquant quelque chose.
Par définition, des fichiers dynamiques changent. En règle générale, ils changent en faisant une sorte de requête de base de données qui affecte le contenu de la page étant servi à l'utilisateur. Par conséquent, vous ne voulez pas cacher le contenu dynamique. Si vous le faites, cela devient simplement du contenu statique et le contenu statique le plus probable avec un contenu incorrect.
En tant que simple exemple, disons que vous avez 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é à la demande de la page qui garantit que le nom propre est affiché. Si vous deviez mettre en cache cette page, la requête de la 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 il ne sera probablement pas leur nom d'utilisateur. Vous avez besoin de cette question pour arriver sur chaque charge de page pour vous assurer que le nom d'utilisateur approprié est affiché à chaque utilisateur. Il n'est donc pas cachéable.
Étendez cette logique à quelque chose d'un peu plus problématique comme les autorisations de l'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 touchée pour le contenu dynamique, le CMS n'a aucun moyen de déterminer si l'utilisateur demandant la page a des autorisations pour voir cette page.
Le contenu statique est, par définition, identique pour tous les utilisateurs. Par conséquent, aucune requête de base de données n'a besoin de personnaliser cette page pour chaque utilisateur afin qu'il ait logique de mettre en cache que 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 à la mise en cache.
Dans votre code ci-dessus, vous voyez un extrait de VCL vernis très typique qui force des images, des CSS et JavaScript à mettre en cache. Par défaut, le vernis ne mettra en cache aucune demande avec un cookie dedans. La logique étant que s'il y a un cookie dans la demande, il doit y avoir une raison quelconque, il doit y avoir une raison pour laquelle le serveur a besoin de ce cookie afin qu'il soit nécessaire à l'arrière et doit être transmis dans le cache. En réalité, de nombreux CMSES (Drupal, WordPress, etc.) attachent des biscuits à presque tout ce qu'il est nécessaire de savoir s'il est commun pour écrire VCL pour dépouiller les cookies du contenu connu pour être statique qui provoque à son tour le cache de cache. ce.
Avoir un sens?
La mise en cache des fichiers statiques avec vernis bénéficierait en termes de déchargement de NGinx. Bien sûr, si vous avez beaucoup de fichiers statiques à cache, il gaspillera RAM. Cependant, le vernis a une belle fonctionnalité - il prend en charge plusieurs backend de stockage pour son cache.
Pour les fichiers statiques: cache au disque dur pour tout le reste: cache à la RAM.
Cela devrait vous donner plus de perspicacité sur la manière de mettre en œuvre ce scénario: http://www.gepagespeed.com/server-setup/varnish-static-files-cache