Pourquoi mettre en cache des fichiers statiques avec Varnish, pourquoi ne pas passer

9

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é.

Saif Bechan
la source

Réponses:

10

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.)

cyberx86
la source
J'aime les remarques que vous avez faites, je viens de commencer à creuser cela et je trouve étrange que la plupart des guides en ligne vous laissent simplement mettre en cache le contenu statique avec du vernis, je parie que certaines personnes mettent en cache des Mo de contenu statique. C'est vrai ce que vous dites, si ce sont de petits fichiers, et si vous avez de la mémoire libre, c'est ok.
Saif Bechan
Cela dit, pour ma part, je n'ai pas la mémoire disponible, et j'ai des fichiers de mise en page de modèle que je ne veux pas mettre sur CDN, je les veux juste dans mon répertoire de modèles. Je vais supprimer l'extrait de ma configuration de vernis qui les met en cache, afin que la mémoire dont je dispose puisse être mieux utilisée. J'ai aimé le conseil sur les 3 configurations différentes. Je pense que je vais juste ouvrir le port vers nginx directement et servir les fichiers de modèle à partir de là. ayant vernis gérer html, nginx gérer statique, et si nessesary php / mysql pour un nouveau contenu.
Saif Bechan
Vous remarquerez que de nombreuses configurations Varish utilisent de nombreux Go de mémoire - correctement configurées, et dans des scénarios réels, je ne doute pas qu'il surpasse nginx; Je peux cependant suggérer que c'est la flexibilité et les options qu'offre Varnish qui le rendent populaire - il est spécifiquement conçu pour la mise en cache. Avec Wordpress, ma configuration préférée est Wordpress + W3TC (+ Cloudfront) + Varnish + Nginx + PHP-FPM + APC. En fait, il n'est pas aussi rapide dans certains cas que d'autres configurations, mais il gère assez bien la charge avec de bonnes performances. Gardez à l'esprit que les pare-feu d'entreprise bloquent souvent les ports non standard.
cyberx86
Par curiosité, pourquoi ne pas garder vos modèles (ce qui signifie probablement CSS / JS - PHP, bien sûr, doivent rester sur votre serveur) sur votre CDN? En outre, une de mes instances ec2 est configurée avec le même principe à l'esprit et comprend les éléments suivants: if (req.url ~ "\.(png|gif|jp(e?)g|avi|flv|mp(e?)g|mp4|mp3)"){return(pass);}dans vcl_recv (). Essentiellement, je ne veux pas mettre en cache les médias - mais je veux vraiment mettre en cache html (php) et même js / css (la théorie étant que les images contribuent moins au temps de chargement de la page perçue que la mise en page).
cyberx86
J'ai vu le w3tc, mais je n'aime pas vraiment utiliser des plugins. Je viens de créer de petits plugins qui prennent en charge des options spécifiques pour chaque site spécifique, donc je sais ce que tout fait. D'un POV de programmeurs, j'ai regardé certains plugins, et certains sont horribles. J'ai créé mon propre plugin minify, le nettoyage direct et le téléchargement de fichiers multimédias vers s3 et cf, un petit plugin memcached et quelques autres. Je n'ai pas encore réussi à créer le plugin final qui prend en charge le téléchargement des modèles sur le CDN.
Saif Bechan
2

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?

jdw
la source
Merci pour la réponse, mais je ne suis toujours pas sûr. Je suis conscient du fait que le contenu dynamique change sur certains sites Web, mais sur d'autres, comme le mien, il ne change pas souvent. J'utilise simplement un CMS pour vous simplifier la vie. Mes pages dynamiques peuvent donc être mises en cache pendant une semaine. Important, oublions la dynamique, je ne comprends pas pourquoi mettre en cache du contenu statique si vous avez nginx comme backend. Si je suis correct, le nginx et le vernis sont tout aussi rapides en contenu statique, ou je me trompe. Une recherche statique peut être gérée aussi rapidement avec nginx qu'avec du vernis. J'ai un peu mis à jour la question.
Saif Bechan
2

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.

Eli
la source
1

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

Danila Vershinin
la source
Juste curieux de savoir pourquoi vous pourriez mettre des fichiers statiques sur un cache de disque dur - n'est-ce pas essentiellement la même chose que de simplement les servir à partir du disque sans cache?
Shane N
Essentiellement, oui :) Mais si Varnish est en place, il doit contacter le backend (Nginx, Apache, peu importe) pour les récupérer. Il ne peut pas le faire directement à partir du système de fichiers. Pour éliminer les frais généraux de la communication dorsale, ils doivent être mis en cache, même sur le disque.
Danila Vershinin
Ah ok, cela a du sens - merci @ danila-v
Shane N