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 :
- Un filesystem dédié
- Ext2 pour évité les opérations de journalisation et gagné quelque I/O
- Un volume de 15Go pour une occupation de 12Go soit 80%
- 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.
