42 votes

Tux, Varnish ou Squid ?

Nous avons besoin d'un accélérateur de contenu web pour les images statiques devant nos serveurs frontaux Apache.

Notre ancien partenaire d'hébergement utilisait Tux avec beaucoup de succès et j'apprécie le fait qu'il fasse partie de Red Hat Linux que nous utilisons, mais sa dernière mise à jour date de 2006 et il semble qu'il y ait peu de chances qu'il soit développé à l'avenir. Notre FAI nous recommande d'utiliser Squid en tant que proxy de mise en cache inversée.

Qu'en est-il de Tux et de Squid ? La compatibilité, la fiabilité et le support futur sont aussi importants pour nous que la performance.

Par ailleurs, j'ai lu dans d'autres fils de discussion ici au sujet de Varnish ; quelqu'un a-t-il une expérience réelle de Varnish par rapport à Squid, et/ou Tux, dans des environnements à fort trafic ?

Santé

Ian

MISE À JOUR : Nous testons maintenant Squid. En utilisant ab pour extraire la même image 10 000 fois avec une simultanéité de 100, Apache seul et Squid/Apache ont brûlé les requêtes très rapidement. Mais Squid n'a fait qu'une seule demande à Apache pour l'image et les a toutes servies à partir de la RAM, alors qu'Apache seul a dû faire appel à un grand nombre de travailleurs pour servir les images. Il semble que Squid sera efficace pour libérer les travailleurs d'Apache afin qu'ils puissent gérer les pages dynamiques.

36voto

scooterXL Points 1221

D'après mon expérience, varnish est beaucoup plus rapide que squid, mais il est tout aussi important qu'il soit beaucoup moins une boîte noire que squid. Varnish vous donne accès à des journaux très détaillés qui sont utiles pour déboguer les problèmes. Son langage de configuration est également beaucoup plus simple et beaucoup plus puissant que celui de Squid.

15voto

Luc Stepniewski Points 313

@Daniel, @MKUltra, pour préciser les problèmes supposés de Varnish avec les cookies, il n'y en a pas vraiment. C'est tout à fait normal pas pour mettre en cache une requête si elle renvoie un cookie. Les cookies sont principalement destinés à distinguer les différentes préférences des utilisateurs, et je ne pense donc pas qu'il soit souhaitable de les mettre en cache (surtout s'ils contiennent des informations secrètes telles qu'un identifiant de session ou un mot de passe !)

Si votre serveur envoie des cookies avec vos .js et vos images, c'est un problème du côté de votre backend, pas du côté de Varnish. Comme indiqué par @Daniel (lien fourni), vous pouvez forcer la mise en cache de ces fichiers de toute façon, grâce au langage/DSL vraiment cool intégré dans Varnish...

12voto

flungabunga Points 197

Si vous souhaitez diffuser des images statiques et en grand nombre, il est préférable d'examiner d'abord quelques principes de base.

Votre application doit s'assurer que tous les en-têtes corrects sont transmis, Cache-Control et Expires par exemple. Cela devrait permettre aux navigateurs des clients de mettre ces images en cache localement et de réduire le nombre de requêtes.

Utilisez un CDN (si votre budget le permet), cela rapproche les images de vos clients (en général) et leur offre une meilleure expérience utilisateur. Pour que le CDN soit un investissement productif, vous devrez à nouveau vous assurer que tous les en-têtes de mise en cache nécessaires sont correctement configurés, comme je l'ai indiqué dans le paragraphe précédent.

Après tout cela, si vous avez l'intention d'utiliser un reverse proxy, je vous recommande d'utiliser nginx en mode proxy, plutôt que Varnish et squid. Oui, Varnish est rapide, et aussi rapide que nginx, mais ce que vous voulez faire est vraiment très simple, Varnish prend tout son sens lorsque vous voulez faire de la mise en cache complexe, et de l'ESI. Donc, restez simple, stupide. nginx fera très bien votre travail.

Je n'ai pas d'expérience avec Tux, je ne peux donc pas faire de commentaires à ce sujet.

6voto

tylerl Points 14541

Pour ce que ça vaut, j'ai récemment mis en place nginx en tant que reverse-proxy devant Apache sur un serveur web de faible puissance vieux de 6 ans (fonctionnant sous Fedora Core 2) qui faisait l'objet d'une légère attaque DDoS (10K req/sec). Le chargement des pages a été rapide (<100ms) et la charge du système est restée faible avec une utilisation du CPU d'environ 20% et une très faible consommation de mémoire. L'attaque a duré une semaine et les visiteurs n'ont constaté aucun effet néfaste.

Ce n'est pas mal pour plus d'un demi-million de visites par minute. Veillez à vous connecter à /dev/null.

4voto

Richy B. Points 1146

Nous utilisons le vernis sur http://www.mangahigh.com et ont pu passer d'environ 100 simultanés avant varnish à plus de 560 simultanés après varnish (la charge du serveur est restée à 0 à ce stade, il y a donc beaucoup d'espace pour grandir !) La documentation de varnish pourrait être meilleure, mais elle est assez flexible une fois que l'on s'y est habitué.

Varnish est censé être beaucoup plus rapide que Squid (n'ayant jamais utilisé Squid, je ne peux pas l'affirmer avec certitude) - et http://users.linpro.no/ingvar/varnish/stats-2009-05-19 montre que Twitter, Wikia, Hulu, perezhilton.com et un certain nombre d'autres grands noms l'utilisent également.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X