Zope est un serveur d’application spécialisé dans la gestion de contenu dynamique. Tout le contenu non contextuel du site, comme les images, les fichiers, les pages statiques ou dynamiques qui ne dépendent pas de l’utilisateur, sont lourds. Pour prévenir la saturation d’un site en cas de forte affluence, une méthode consiste à mettre en ?”uvre une configuration desservant par un serveur proxy-cache installé en amont de Zope, ce contenu non textuel. Ce dernier est conçu pour conserver des éléments de sites web (pages, images, fichiers, etc.) à proximité immédiate des postes clients du réseau. Son rôle consiste à minimiser la consommation de la bande passante par un groupe d’internautes, localisés sur un réseau d’entreprise par exemple. Une autre façon d’utiliser un proxy consiste à le faire fonctionner “à l’envers“, c’est-à-dire pour distribuer les objets d’un site à tous les navigateurs qui s’y connectent. En cas d’affluence, le serveur d’application ne s’effondre pas. Il utilise ses ressources processeur pour délivrer les pages les plus complexes dans des temps acceptables. Squid, le plus performant des serveurs proxy et de cache, est disponible via une licence Open Source.
1. Installez Squid
Téléchargez la dernière version stable de Squid à partir de l’adresse “
squid-cache.org
“, puis procédez à l’installation de l’archive. Selon votre configuration spécifique (Red Hat, Debian ou autre), cette procédure va installer tous les fichiers programmes et de configuration de Squid dans un répertoire du type “/usr/local/squid” (voir code 1 ci-contre).
2. Ajustez les permissions Unix pour l’exécution de Squid
Pour éviter que Squid ne s’exécute en tant qu’utilisateur “root“, ce qui présente des risques de sécurité pour le site, éditez le fichier de configuration “squid.conf” présent dans “/usr/local/squid/etc” et enlevez le caractère “#” précédent les deux lignes suivantes pour les activer :
cache_effective_user nobody
cache_effective_group nobody
3. Paramétrez le cache et les fichiers journaux (logs)
Pour définir une taille du cache de 100 Mo, modifiez la directive “cache_dir” du “squid.conf” comme suit : “cache_dir /usr/local/squid/ cache 100 16 25“. Bien entendu, il faut adapter la taille du cache à la taille de votre site. Il est recommandé d’utiliser le double d’espace qu’utilise votre site web sur le disque.
4. Démarrez Squid
L’installation place dans le sous répertoire “bin” un script Shell nommé “RunCache” chargé de maintenir la fonction de cache active. Démarrez Squid à l’aide de la commande :
“$ /usr/local/squid/bin/RunCache &” Plus tard, pour les besoins du site en production, vous pourrez ajouter cette ligne à votre fichier “/etc/rc.local“, par exemple, afin que le serveur Squid soit démarré au “boot” de la machine.
5. Paramétrez Squid en mode d’accélération HTTP
Il s’agit de configurer Squid pour qu’il reçoive et transfère toutes les requêtes HTTP vers un port différent du port HTTP par défaut (80), sur lequel s’exécuterait le véritable serveur web. Modifiez les directives suivantes dans le fichier “squid.conf“, après les avoir “décommentées” si nécessaire (voir code 5 ci-contre).Grâce à la première directive (ligne 1), le serveur proxy s’exécutera sur le port 80, le port standard des requêtes HTTP. Les lignes 3 et 4 spécifient le nom DNS de la machine du serveur à accélérer et le port sur lequel ce dernier s’exécute. En effet, par conception, le serveur Zope fonctionne sur le port 8080. La ligne 2 gère le contrôle d’accès. Par défaut, l’accès est interdit à tout le monde via la directive “http_access deny all“. Il faut donc la modifier pour permettre l’accès à tous.
6. Rendre le changement de port transparent pour l’internaute
Il convient maintenant de modifier Zope pour ne pas révéler à l’internaute que sa requête est en réalité servie sur un port non standard, le 8080. La modification requise se fait simplement, via l’interface de management de Zope, en utilisant le module “SiteAccess” disponible en standard dans votre installation Zope. Créez, dans la racine de votre espace d’objets Zope, un objet de type “SiteRoot“. Entrez “
http://www.monsite.com
” dans le champ “Base” et “/” dans le champ “Path“.
7. Modifiez les en-têtes de réponse HTTP
Lorsqu’un serveur web répond à une requête HTTP, celui-ci envoie d’abord les en-têtes HTTP, avant le contenu HTML. Ils ne sont vus que par le navigateur et les éventuels serveurs de cache intermédiaires.Un en-tête de type “Cache-Control” permet au serveur de cache de savoir s’il est obligé de conserver un objet dans son cache, et à quel moment il doit supprimer la version stockée et demander au serveur web une version plus “fraîche“. Modifiez l’en-tête de Cache-Control “max-age” pour les pages qui ne changent pas souvent, grâce à l’appel de la fonction “RESPONSE.setHeader()” au début de l’objet “index_html” qui les définit. La valeur de 3600 représente la durée en secondes pendant laquelle vous voulez qu’un objet soit stocké dans le cache. Adaptez-le à votre cas particulier (voir code C ci-contre).
8. Actions correctives
Le jour où le serveur n’arrive plus à supporter la charge, l’administrateur, alerté par ses outils de surveillance, doit prendre des actions correctives rapides. Il peut créer une page statique “index_html” à la place de la page d’accueil habituelle, avec un message prévenant les utilisateurs. Ensuite, il met rapidement en place un serveur de secours sur une machine prévue et pré-installée pour ce cas précis. Pour remettre le site en route, il lui suffit alors de copier depuis le premier serveur les fichiers spécifiques tels que “/usr/local/zope/var/Data.fs“, la base des objets de Zope (si Zope est installé dans le répertoire Linux “/usr/local“).
9. Dernier recours
Si un problème survient à cause d’une charge trop importante, vous pouvez minimiser l’impact et remettre en service le site sur un serveur de secours en moins d’une heure.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
