Voici.fr : Optimiser les performances reverse proxy de SQUID

Une architecture de reverse proxy et après ?

Vous avez configuré votre application pour tirer partie le mieux possible des possibilités offertes par les caches web comme nous l’avons fait dans notre utilisation de eZ Publish pour les sites web du groupe Prisma-Presse.

Mais après cette optimisation ? Kathryl a publié un billet sur l’optimisation des performances de SQUID utilisé en reverse proxy. Il ce base sur notre expérience commune dans la gestion de l’hébergement des sites web du groupe Prisma Presse. Les sites à très forte audience comme Voici.fr, Gala.fr, Femmeactuelle.fr bénéficie des optimisations qu’il présente dans sa documentation.

J’ai souhaité ajouter quelques précisions sur le sujet et expliquer comment vous arrivions à répondre a 92,23% des requêtes HTTP avec nos reverses proxys comme je l’avais annoncé dans un commentaire sur un billet précédent. Kathryl et moi versons parfois dans la bataille d’expert mais c’est par ce jeu de confrontation technique que nous avons trouvé des solutions aux défis qui ce présentaient à nous. Le principal de ces défis relevé est d’avoir trouvé comment soutenir l’audience montante des site du groupe sans la moindre aquisition de matériel depuis un an, mais ceci fera l’objet d’un billet sur le cost killing dans le web hosting.

L’OS : Debian Lenny 64bits

Pourquoi le 64Bits ? Parce que nous recherchons les performance et que c’est l’architecture qui offre la possibilité d’affectation d’un gros volume de mémoire à un même processus. Dans la cas présent nos services squid joues avec plus de 3Go rien que pour le cache mémoire je pense que c’était indispensable.

Gestion de la mémoire RAM avec Squid

La FAQ de squid proxy est très claire au sujet de la mémoire. Plus squid est configuré avec un stockage disque important via la directive cache_dir plus il aura besoin de mémoire pour en ordonné l’utilisation. Mais en outre plus vous allouez d’espace de mémoire pour squid via la directive cache_mem plus squid aura besoin de mémoire vive, en dehors du quota alloué par cette directive, pour ordonner la aussi les objets stocker dans ce cache.

En résumé plus vous allouez de mémoire de cache, en RAM ou sur Disque, plus vous devez prévoir de mémoire vivre à la disposition de l’application.

Kathryl dans son billet propose un rapport de 1 à 4 entre la mémoire cache alloué via la directive cache_mem et la mémoire RAM total disponible. Le rapport n’est que de 1 à 1,3 actuellement en production sur l’étage reverse proxy. Dans tout les cas surveiller bien que la machine n’utilise pas le swap dans le cas contraire les ralentissements arrivent et vous avez tout faux, il faut revoir vos valeurs. Nous avions fait cette erreur d’allouer trop de mémoire via la directive cache_mem et nous avons ralentis nos reverse proxys du fait de l’utilisation du swap.

Taille des objets en cache mémoire

Kathryl avance la question suivante a la quelle je souscris totalement: En quoi est il pertinent d’accepté en mémoire cache RAM des objets volumineux ? Dans le cas des sites qui nous occupe cela n’a pas d’utilité le réglage du backoffice assurant de ne pas avoir des objets trop gros dans le storage de l’application. Dans notre cas nous avons limité la taille des objets présent dans la mémoire vive de cache pour les cantonner au cache disque via la directive maximum_object_size_in_memory. Vous pouvez aussi via la directive maximum_object_size limité en disque également la taille des objets

Si vous diffusez des objets volumineux comme des pdf ou des archives zip il est intéressant d’accepter de relativement gros objets dans votre cache. Dans tout les cas ne pas négligé ces paramètres, il vous permettrons de mettre en évidence la présence de gros objet sur votre site si vous les refuser car vos frontaux web seront sollicité directement ou au contraire vous offrirons la solution pour leur diffusion.

Espace de cache disque

Dans le cas de notre architecture reverse proxy nous avons fait les choix suivant pour l’accueil de l’espace disque alloué avec la directive cache_dir :

  1. Un filesystem dédié
  2. Ext2 pour évité les opérations de journalisation et gagné quelque I/O
  3. Un volume de 15Go pour une occupation de 12Go soit 80%
  4. option noatime dans /etc/fstab

Si vous disposez d’un gros disque SSD je vous invite à l’utiliser dans ce cadre, personnellement je rêve de voir les performances possible. De même si vous avez la possibilité de raid0 sur un paquet de disque rapide ne vous privez par surtout. Je vous recommande la lecture de la documentation squid cache disk io performance enhancements qui vous apportera beaucoup d’information. Le benchmark de FileSystem suivant vous apportera quelque informations. Personnellement je préfère la solution ext2 à tout autre. Attention Kathryl est mono-maniac de XFS mais cela tiens, je pense à ces habitues de feignant consistant à faire de dump pour migré ces données 🙂

Les logs

Comme le souligne Kathryl lorsque l’on fait très forte audience, les logs par leur écriture ralentisse les serveurs (apache ou squid). Personnellement si je le pouvais je les désactiverais complètement et constamment. Dans quelque cas nous avons trouvé avec cette solution la bouffé d’air frais pour re-stabilisé une architecture ou répondre ponctuellement à une surcharge. Mais, bon, c’est mal et juridiquement interdit car il y a une obligation légale de fournir aux autorités sur présentation d’une réquisition judiciaire les ip des internautes visiteurs.

Il vous reste à étudier

Méthode de cache de Squid

Liser les préconisations de Kathryl sur le sujet, il à un préférence pour DISKD. Nous utilisons UFS en production . Je découvre le passage sur les méthode de cache disque de la documentation de Funkywizard qui lui préfère COSS

Connexions

Kathryl est partisans du « lâché moi la jambe ». Les serveurs de cache ne sont pas la pour garder des sockets ouverts trop longtemps. Il préconise de refuser les connections persistantes. C’est un chose que nous n’avons pas testé plus en avant.

11 réflexions sur “ Voici.fr : Optimiser les performances reverse proxy de SQUID ”

  1. Bonjour,

    Comment testez-vous les modifications de directives de vos fichiers de conf ? Surtout que les performances sont liées au nombre conséquent de connexion.

    Merci

  2. Alors docteur, simple, on ouvre la porte, on met en production, on tend l’oreille tout en gardant un oeil sur cacti !

    Bon en faite c’est un poil moins cowboy. Nous avons une ferme de serveur d’hébergement virtuel Xen qui nous permet de modéliser l’architecture, donc entre autre notre couche squid. On développe et teste sur ce modèle avant de passer en production.

    La mise en production ci fait d’abord sur un serveur et là, oui, on tend l’oreille tout en gardant un oeil sur cacti. Mais à cette étape nous somme sur que notre conf est opérationnel on doute juste de la performance. Un fois que ce serveur initial est en route on reporte la même conf sur les autres.

    L’observation du résultat ce fait sur plusieurs jours.

  3. Ok, vive la virtualisation et les logiciels libres.

    J’ai le droit à un abonnement à voici ? ;-))

  4. Ta remarque sur les logs m’interpelle :
    un log http c’est un log de 100% des requêtes http… mais juridiquement est-ce qu’on en a vraiment quelque chose à faire de savoir que l’ip 1.2.3.4 a demandé logo.png + header.jpg + … est-ce que quelque part ne stocker que les demandes de pages (.php / .html …) ne serait pas suffisant aux yeux de la loi ?

  5. Bonne question Ratatouille. Mais malheureusement tu ne peux pas sur squid ou apache enregistré uniquement certains appel et pas d’autre. J’ai rapidement et vaguement cherché mais je n’ai rien trouvé.

    Par contre ! Si au moment de la conception de ton service tu à pensé à faire des silo fonctionnel comme par exemple avoir un sous domaine différent adréssant sur des serveurs différents pour les images tu peux n’enregistrer tes log que pour une partie de l’architecture.

  6. Très bonne idée en effet

    Même si on met en place un mini cdn hosté sur les mêmes machines, il suffit de faire un virtual host différent et de le configurer pour ne pas loguer… je vais réfléchir à cette idée…

  7. Sur le même serveur avec des vhost différents c’est une bonne idée ratatouille. J’aime bien ce genre d’idée ou tu gagne presque rien (1% de ressources) mais ou tu peux faire la différence.

    Reste que plusieurs serveurs (le pluriel commence a 2) avec une ferme juste dédier à cracher des binaires, avec ngix ou lighttpd, sans les log, sera une solution plus efficace.

  8. Concernant les logs, il est possible de positionner une variable pour les images, et de ne pas logguer les accés à celles-ci :

    Un exemple pour ne pas logguer les accés à des images gifs

    SetEnvIf Request_URI \.gif$ gif-image
    CustomLog access.log common env=!gif-image

  9. Merci Kiru, limité l’écriture des logs est un bon moyen d’accélérer un site web. Par contre c’est un peu plus de mémoire et de cpu sollicité.

  10. ou utiliser syslog ou la directive « BufferedLogs On » pour écrire les logs mais par lot et non pas en live, ça change tout au niveau i/o (mais en cas de gros crash vous perdez quelques logs)

  11. Bonne idée Yo man
    Perso depuis j’ai fais le choix d’envoyer les access log apache sur un syslog central et de plus rien écrire en local.

Laisser un commentaire