Antoine Benkemoun

01 Sep, 2010

Accélérer son site web avec Squid – 1

Posté par Antoine dans la catégorie Blog|Libre|Réseau|Système|Virtualisation

La rapidité de l’Internet est une préoccupation omniprésente car elle améliore significativement l’expérience utilisateur. De plus, récemment Google a annoncé que la rapidité d’affichage des sites serait prise en compte dans le calcul de l’affichage des pages de résultat de recherche. Cette prise en compte avait de quoi en motiver plus d’un à accélérer l’affichage de son site, dont moi.

Contexte

L’affichage de ce blog était relativement lent. Il pouvait mettre plus de 5 secondes pour s’afficher complètement ce qui n’est pas un temps d’affichage très bon. J’ai donc entrepris de trouver une solution à ce problème.

Ce site est hébergé sur une machine virtuelle Xen dont le système d’exploitation est OpenSolaris 2009.06. Elle est globalement assez lente car relativement peu de mémoire lui est alloué. De plus, la cohabitation d’Apache et de MySQL sur le même système ne favorise clairement pas les choses. Certains médisants diront que WordPress et/ou PHP sont des facteurs de lenteur. Ils auront raison mais je n’ai aucune intention d’utiliser autre chose que WordPress car c’est un réel plaisir à l’utiliser.

Un peu de théorie

Un proxy ou en Français « serveur mandataire » est un serveur qui se place entre le client et le serveur. Le client va interroger le proxy qui va à son tour interroger le serveur. Le serveur répondra au proxy qui, à son tour, répondra au client. Ceci est le fonctionnement le plus classique mais on peut placer un proxy dans nombreuses configurations et donner au proxy une intelligence supplémentaire.

Dans le cas de proxys HTTP(S) classiques, on y ajoute des mécanismes de cache afin d’économiser de la bande passante. On peut également y ajouter des fonctions de filtrage d’URL afin d’éviter la consultation de certains sites.

L’exemple d’application du proxy qui nous intéresse ici est le reverse proxy. Le client n’aura aucune connaissance de la présence d’un proxy et pensera qu’il s’agit d’un serveur HTTP comme un autre. Le proxy interrogera ensuite le serveur web et la requête sera renvoyée au client. Dans cette situation, la fonctionnalité de cache du proxy est très intéressante car elle permet d’éviter le traitement de certaines requêtes au serveur HTTP. On pourrait également utiliser le proxy couplé à plusieurs serveurs HTTP afin d’effectuer du load balancing et de la redondance.

Une autre VM

La première étape a été de trouver une machine supplémentaire afin de ne pas faire cohabiter la pile LAMP et Squid sur le même serveur. Dans l’absolu, ce n’est pas impossible mais lorsqu’on a un serveur déjà surchargé, ce n’est peut être pas la meilleure idée.

Étant donné qu’OVH vient de lancer son offre miniCloud, ce projet était une parfaite excuse pour la tester. Le prix de cette offre est vraiment très bas. Pour une VM de 256Mo de RAM, cela revient à 8,5€/mois. J’ai donc crédité 10€ sur mon compte. L’interface de gestion n’est pas la plus esthétique ni la plus rapide mais elle fait l’affaire.

En une petite dizaine de minutes, j’avais donc à ma disposition une machine virtuelle Debian Lenny 64-bits. Le réel inconvénient de l’offre d’OVH est que l’IP de la machine virtuelle change à chaque fois que vous l’arrêtez par le biais de l’interface de gestion.

L’installation de la pile LAMP est très simple et je ne la détaillerai donc pas ici. Il existe des masses incroyables de documentation à ce sujet.

Squid

L’installation de Squid est très simple. Je l’ai installé sur OpenSolaris à partir des dépôts Blastwave via pkgutil. Dans le cas de Debian, un apt-get s’occupera de tout ca pour vous.

Une fois installé, nous pouvons passer à sa configuration. La configuration du reverse proxy est la suivante :

http_port 80 accel defaultsite=www.antoinebenkemoun.fr
visible_hostname vm.antoine.fr
cache_peer 178.32.yy.xx parent 80 0 no-query originserver name=myAccel
acl all src 0.0.0.0/0.0.0.0
cache_peer_access myAccel allow all
acl our_sites dstdomain antoinebenkemoun.fr www.antoinebenkemoun.fr antoinebenkemoun.com www.antoinebenkemoun.com
http_access allow our_sites

Tout d’abord, on indique à Squid d’écouter les requêtes sur le port 80 et que le site que l’on va proxy-er est « www.antoinebenkemoun.fr ». Ensuite, on lui indique l’IP du serveur web où est réellement hébergé le site. Il est ensuite nécessaire de définir un certain nombre d’ACL qui sont ici assez génériques et tout à fait simples. Dans l’exemple, nous avons autorisé le reverse proxy pour 4 sites et nous avons autorisé toutes les IP à visionner le site.

Il est également possible d’utiliser d’autres options afin de mieux régler votre reverse proxy. L’ajout d’un « access log » va vous permettre de voir les pages qui sont consultés mais surtout si le contenu est envoyé par Squid ou par votre serveur LAMP. Il est également possible de régler la quantité de mémoire vive utilisé pour le cache de pages web. L’espace mémoire utilisé pour le cache sera donc alloué en plus de l’espace mémoire du programme principal.

cache_mem 20 MB
cache_access_log /opt/csw/var/logs/access.log

Le chemin pour l’access log est adapté à mon OpenSolaris mais à vous de l’adapter à votre distribution. Si vous êtes sur Linux, vous voudrez surement placer les logs quelque part dans /var/log/.

Au final, nous avons installé notre serveur Squid et l’avons configuré en mode reverse-proxy. Dans le billant suivant, nous verrons les modifications qu’il faut apporter à notre serveur Apache afin d’utiliser réellement la fonctionnalité de cache du reverse proxy.

17 Commentaires to "Accélérer son site web avec Squid – 1"

1 | Ulhume

septembre 1st, 2010 at 18 h 39 min

Avatar

Ce qui n’ôte rien à ton article et à Squid, une alternative très utilisée comme reverse proxy est Varnish (http://varnish-cache.org/). Il a l’avantage d’être programmable mais aussi d’être contrôlable par le site qu’il cache.

2 | Geoffrey

septembre 2nd, 2010 at 7 h 11 min

Avatar

+1 avec Ulhume, varnish permet aussi de lisser la charge coté serveur, chose que ne permet pas Squid.
Mais on ne lui en veut pas, à la base il est pas spécialisé dans le reverse proxy :D

3 | Denis

septembre 2nd, 2010 at 7 h 59 min

Avatar

Alors, là, je n’en reviens pas. C’est ce que j’ai fait hier soir… de guerre lasse : Squid en mode transparent. Résultat des courses : PRODIGIEUX !

J’avais auparavant mis en cache MySQL, Apache, utilisé les extensions DB Reloaded et WP Supercache sous WordPress ! Je vais faire le tri. L’apport du proxy est tout simplement prodigieux. Je l’ai installé sous Centos de base ! J’ai aussi mis eAccelerator.

Rq Ce qui peut être intéressant, c’est de coller un Awstats sur les logs de Squid.

NB Connais pas Varnish. qu’est-ce qu’il apporte par rapport à Squid ?

4 | Ulhume

septembre 2nd, 2010 at 8 h 49 min

Avatar

@Denis comme évoqué dans mon post, Varnish est conçu pour être un reverse proxy utilisé pour mettre en cache les sites dynamiques. Entre autre fonctionnalités, ton application web (par exemple en PHP) peut contrôler la validité du cache de certaines page (genre « vide le cache de cet article car un commentaire a été ajouté »). Tu peux aussi « programmer » Varnish pour s’adapter à toutes les situations (ex. Si tu vois le cookie « user_id », tu ne mets pas en cache cette page). Tu as aussi un espèce de langage de pages permettant de mixer contenus statiques et dynamiques (sans avoir à passer par de l’ajax).

Bref, il est juste fait pour cela et écrit dans l’idée d’être ultra rapide.

5 | Denis

septembre 2nd, 2010 at 9 h 35 min

Avatar

Grand merci. Je vais voir si je le trouve en paquet sur Centos.

@Antoine

Big problème avec Askimet en mode proxy transparent !

6 | Nicolargo

septembre 2nd, 2010 at 9 h 58 min

Avatar

Je suis justement en train de réunion des informations pour écrire un billet sur l’optimisation des blogs sur des serveurs VPS ! Ton article tombe bien.

Juste une question, quand est il des statistiques des blogs qui se trouvent derrière ces proxys ? Des service comme Google Analytics ne seront il pas trompé par le cache ?

7 | Denis

septembre 2nd, 2010 at 10 h 25 min

Avatar

@Nicolargo

Pour ma part, il ne s’agit pas d’un reverse proxy. Il s’agit d’un proxy de sortie.

Dans le cas d’un reverse proxy, il faut les stats sur les logs de Squid avec Awstats.

8 | Antoine

septembre 2nd, 2010 at 10 h 56 min

Avatar

Pfiouuu que de commentaires !
@Nicolargo, pas de soucis pour les script de stats en JS ce qui est le cas de Google Analytics et WordPress Stats. Au pire tu peux régler ce que tu autorises à mettre en cache ou pas.

@Denis, qu’as-tu comme soucis avec Akismet ?

@Ulhume, j’avais déjà entendu parler de Varnish. Ca a l’air effectivement très intéressant comme application ! J’y jetterai un coup d’oeil à l’occasion. L’idée ici était de trouver une solution rapide et facilement installable sur mon OpenSolaris.

Truc assez pénible sur les VPS OVH, le mail est bloqué en sortie et j’ai donc du mettre un VPN qui est down depuis ce matin! Et oui, sinon c’est pas rigolo !

9 | Denis

septembre 2nd, 2010 at 11 h 32 min

Avatar

En erreur. J’ai bien essayé les paramètres WordPress.

define(‘WP_PROXY_HOST’, ‘ip_du-serveur’);
define(‘WP_PROXY_PORT’, ‘port’);

Rien n’y fait. Faut que je gère des exceptions au niveau iptables ? S’il y a plus simple, je suis preneur !

NB Je vais coupler un reverse proxy pour le fun.

10 | Antoine

septembre 2nd, 2010 at 15 h 01 min

Avatar

@Denis, je n’en ai aucune idée. Avec la configuration mentionnée dans le billet, je n’ai pas eu de soucis.

11 | Denis

septembre 2nd, 2010 at 16 h 14 min

Avatar

@antoine

Toi, tu l’as mis en reverse proxy. Moi, je l’ai mis pour limiter les requêtes en sortie par NAT :

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -i eth0 -p tcp –dport 80 -j REDIRECT –to-port 3128
COMMIT

Le résultat est très intéressant.

12 | Antoine

septembre 2nd, 2010 at 22 h 48 min

Avatar

@Denis, Ok je vois ce que tu as fait. C’est une sorte de reverse proxy transparent comme on peut faire pour filtrer du web en proxy transparent. Je ne vois pas trop en quoi ca changerait quelque chose pour Akismet au delà du fait qu’il n’ait plus l’IP source du message…

13 | Denis

septembre 3rd, 2010 at 6 h 42 min

Avatar

A priori, problème d’en-tête, m’a-t-on indiqué chez Askimet ? Ils m’ont fourni une astuce. Mais ça ne marche pas ! Je cherche. En attendant, j’ai mis le plugin BitDefender. Je verrai bien.

14 | Solutions pour accélérer WordPress

septembre 15th, 2010 at 15 h 10 min

Avatar

[…] Antoine Benkemoun a réalisé un article « éclairant » au sujet de la mise en place d’un reverse proxy avec Squid. […]

15 | Le petit journal du web : HTML5, CSS3, jQuery, WordPress, Métiers du Web, Vie quotidienne et Nostalgeek

octobre 12th, 2010 at 9 h 58 min

Avatar

[…] fichiers CSS, les fichiers Javascript, les images, le serveur et le core de WordPress. Lire aussi Accélérer son site web avec Squid et Architecture pour un blog […]

16 | Bartounet

novembre 11th, 2010 at 9 h 34 min

Avatar

1- Très bon article, mais il aurait été interessant d’avoir de manière chiffrée les gains de rapidité/performance.

2- Tu dis que tu utilise un DomU Xen pour tes VM, j’utilise moi même cette technique, j’ai 5 DomU qui tournent sur une kimsufi 750G ( Quad core Q6700 + 4Go ram)
Tes DomU sont paravirtualisés ?

17 | Accélérer les plates-formes LAMP | Blog Exia.Cesi, école informatique supérieure du groupe Cesi

novembre 15th, 2010 at 18 h 14 min

Avatar

[…] a réalisé un article « éclairant » au sujet de la mise en place d’un reverse proxy avec Squid. Dans la même famille, signalons encore l’excellent proxy, […]

Ajoutez votre commentaire

A propos de ce blog

Ce blog a pour objectif de partager des informations avec tous les internautes. Comme indiqué dans le titre, je traiterais de différrents sujets gravitant autour de la sécurité informatique, de la virtualisation, de la l'administration système et du réseau.