Les billets précédents évoquaient l’amélioration de performances d’un site web grâce à un astucieux montage basé sur plusieurs machines virtuelles. Aujourd’hui, nous allons parler de benchmarking de site web.

Quelques rappels

L’expression « benchmarking » est devenue très populaire dans le milieu professionnelle comme de nombreux autres termes anglais cherchant à démontrer un dynamisme et une originalité. Nous parlerons ici que de sa signification originale qui est la mesure de performances.

Sur l’Internet, l’utilisateur ne demande plus rien d’autre que de l’instantané. Si votre site met plus de quelques secondes à s’afficher, l’utilisateur passera probablement son chemin malgré la qualité éventuelle du contenu.

Les outils pour mesurer les performances des sites web ne manquent pas à l’appel. On en trouve de nombreux en ligne et sous forme d’applications. Certains présentent une originalité intéressante alors que d’autres se cantonnent à des fonctionnalités basiques. L’outil le plus connu est probablement « ab » car il est souvent installé en même temps qu’Apache. Cet outil dispose de fonctionnalités intéressantes mais relativement basiques.

Tsung

Comme l’indique le titre, nous allons nous intéresser à Tsung. Il s’agit d’un projet Open Source Français développé par Nicolas Niclausse. Cette application ne se limite pas aux sites web via HTTP mais peut également benchmarker les applications Webdav, SOAP, MySQL, PostgreSQL, LDAP et Jabber/XMPP. La mesure de performances peut se faire d’une seule machine ou de tout un cluster.

Tsung permet de générer et d’exécuter des scénarios de test. Cela signifie qu’il ne se limite à charger une page web selon une fréquence définie. Vous allez pouvoir lui faire naviguer votre site et utiliser diverses fonctionnalités.

Fonctionnement

L’enregistrement de scénarios est très simple. Il vous suffit de lancer le « tsung_recorder » et de le paramétrer en tant que proxy de votre navigateur. Les actions que vous allez ensuite effectuer dans votre navigateur vont être enregistrées. Vous aurez ainsi créé une suite d’actions.

Une fois la suite d’actions créée, il sera nécessaire de paramétrer les informations relatives au scénario,  à savoir l’IP du serveur à tester, la fréquence d’exécution, etc. La documentation de ce projet est claire à l’exception du chapitre sur les fichiers de configuration de scénario. Pour cela, je vous donne un fichier de configuration de scénario complet et fonctionnel qui devrait vous permettre d’y voir un peu plus clair.

Une fois la configuration terminée, il ne vous restera plus qu’à l’exécuter et observer votre serveur travailler.

Analyse des résultats

L’exécution d’un scénario de benchmarking est une chose mais l’interprétation des résultats est essentielle. Tsung a tout prévu pour vous.

Grâce à l’utilitaire « tsung_stats », vous allez pouvoir générer une série de graphiques traduisant les résultats du test. Cet utilitaire prendra même le soin de les mettre en page dans une page web. L’image ci-dessous est un exemple (en version réduite) des graphiques en question. Un fichier vectoriel est également généré si vous souhaitez disposer d’un visuel plus flexible.

Si vous souhaitez comparer les résultats, Tsung met à votre disposition l’outil « tsplot » qui vous génèrera des graphiques comparant les différents tests que vous avez exécuté. L’image ci-dessous est un exemple de graphique généré par tsplot.

Au final, Tsung est un excellent outil permettant de créer simplement des scénarios de benchmarking complexes et de visualiser ces résultats à travers des graphiques clairs. Seul bémol, il ne s’agit pas d’un logiciel particulièrement simple à utiliser car tout se fait en ligne de commande. Cependant, un utilisateur de Linux un peu aguerri devrait pouvoir s’en sortir.

Rappels

Historiquement, les proxy HTTP ont été mis en place afin d’accélérer les chargements des pages web. A une certaine époque l’acronyme WWW pouvait avoir pour signification « World Wide Wait ». La solution apportée à ce problème a été de mettre en cache les contenus au plus proche de l’utilisateur par le biais de proxy.

La gestion du cache HTTP doit être géré du coté du fournisseur de contenu, à savoir le serveur web. En théorie, ce dernier a autorité sur les données du site qui pourront être mises en cache ou non. Ces informations sont transmises dans les en-têtes HTTP par le biais de divers champs que nous ne détaillerons pas tous ici. Un champ particulièrement intéressant est la durée de rétention dans le cache.

Par défaut, Apache n’envoie pas d’informations quant à la mise en cache du contenu ce qui signifie donc qu’en théorie les données de notre site ne seront pas mises en cache. Dans notre situation, cela signifie que Squid ne met rien en cache tant que nous n’avons pas configuré Apache pour lui indiquer qu’il est possible de le faire.

Configuration d’Apache

Nous allons donc devoir paramétrer Apache pour utiliser les en-têtes contrôlant la mise en cache de nos pages web. Ainsi, notre serveur Squid pourra prendre une partie de la charge de notre serveur web et ainsi le soulager.

Le module Apache qui nous intéresse plus particulièrement est mod_expires. Son activation est simple et, dans le cas de Debian, il est packagé avec Apache. Il suffit donc de l’activer comme suit.

# a2enmod expires

# /etc/init.d/apache2 restart

Une fois ce module activé, nous allons pouvoir le configurer.

Configuration de mod _expires

Nous allons pouvoir configurer mod_expires par le biais de fichiers .htaccess comme il est possible de le faire pour bon nombre d’autres modules. Ce module nous permet de gérer assez finement la mise en cache des fichiers. La syntaxe est simpliste mais efficace. Si vous souhaitez obtenir une explication exhaustive dans la syntaxe et de ses fonctionnalités, je vous recommande de consulter la documentation.

Pour ce site, j’ai choisi la politique suivante de mise en cache.

ExpiresActive On
ExpiresByType image/gif « access plus 1 week »
ExpiresByType image/jpeg « access plus 1 week »
ExpiresByType image/png « access plus 1 week »
ExpiresByType text/css « access plus 1 days »
ExpiresByType application/x-shockwave-flash « access plus 1 hour »

Ensuite, c’est à vous de voir ce que vous voulez que Squid mette en cache ou pas en fonction des fonctionnalités de votre site.

Vérification

Afin de vérifier si tout fonctionne correctement, je vous invite à consulter les log d’accès à votre serveur Squid. Des lignes comportant « TCP_HIT » s’afficheront lorsque Squid servira des données du cache à la place d’Apache. Si vous n’avez que des « TCP_MISS », il doit probablement manquer un élément à votre configuration.

Au final, cette méthode permet d’accélérer significativement son site web et ainsi d’améliorer son référencement sur Google. Dans mon cas, le temps de chargement de ce site a été divisé par un facteur 2 à 3 ce qui est tout de même très intéressant. Des lecteurs m’ont fait remarquer qu’il existait une alternative plus moderne à Squid, Varnish qui permettrait de définir des politiques de mise en cache plus fine. Je vous laisse donc y jeter un coup d’œil !

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.

Problématique

Le besoin initial de cette application est la gestion des règles iptables d’un parc de machines. En tant qu’administrateurs système, nous ne retrouvons régulièrement à gérer des scripts iptables sur divers serveurs. Lorsqu’on gère 5-10 serveurs, la gestion à la main reste acceptable. Cependant, dès que l’on commence à gérer plus de serveurs, ca commence à devenir réellement long et fastidieux. Et qui dit fastidieux dit fort potentiel d’erreurs.

J’ai donc entrepris de créer une application qui permettrait de gérer tout ca de manière un peu plus automatisée. L’application Netfilter Manager est donc née. Le nom est pas tout à fait extraordinaire mais ca représente à peu près ce que ca fait.

Présentation

Netfilter Manager utilise donc une interface en ligne de commande afin de pouvoir gérer un lot d’hôtes et les règles associées. Cette CLI est inspirée quelque peu de la CLI Cisco pour ceux qui ont déjà eu la chance l’occasion de l’utiliser. La licence de l’application est GPLv3. J’avoue ne pas être un expert dans le domaine des licences de logiciel mais c’est une des plus répandues et le peu que j’en connais me convient.

Chaque hôte dispose d’un nom et d’une adresse IP. A la place de l’adresse IP, on peut bien sûr utiliser un nom DNS que le serveur de gestion saura résoudre. L’application ne supporte que pour l’instant Iptables, il n’est donc pas encore possible de sélectionner un type d’hôte mais c’est une fonctionnalité envisageable.

Les règles sont ajoutées hôte par hôte et peuvent être organisées par ligne. Par défaut, les règles que vous ajoutées sont ajoutés à la suite des règles existantes. Il est possible de gérer plus finement l’ordonnancement des règles en utilisant la gestion par ligne. Chaque ligne peut comporter plusieurs règles et les règles seront appliquées dans l’ordre croissant des lignes. Ce comportement est très similaire au mode de fonctionnement des access-list Cisco.

Voici un petit exemple d’utilisation :

Il est également possible de créer des lots de règles grâce à un moteur de template dont l’utilisation est expliquée dans le README. Vous trouverez un exemple de template dans le fichier cobalt.tpl présent dans le répertoire templates.

Une fois que vous avez créé toutes les règles de firewall, vous allez pouvoir les « pousser » vers vos serveurs. Un script contenant les règles est généré en prenant les règles que vous avez spécifié et en ajoutant au début le contenu du fichier start.tpl. Par défaut, ce fichier contient des règles permettant de supprimer les règles iptables actuellement utilisées.

Pour en savoir plus sur l’utilisation de l’application, la commande help devrait pour vous aider. Sinon je vous conseille de lire le README (en anglais pour l’instant). J’espère que les explications sont claires et vous permettront de réussir à utiliser l’application. Si ce n’est pas le cas, vous pouvez me le faire savoir soit par ce blog soit par le bugtracker de github.

Bonus

En petit bonus, j’ai ajouté la possibilité de créer des règles en utilisant la syntaxe Cisco. Pour l’instant, seuls les règles IP sont supportées mais les règles TCP/UDP devraient également être supportées par la suite. Dans le mode ajout, il faut utiliser la commande access-list. Un page d’aide a été spécifiquement ajouté, vous pouvez y accéder en tapant access-list help. Je ne suis pas sûr que ce soit d’une utilité débordante mais ca m’a bien amusé de le coder.

Code

Tout le code de l’application est disponible sur github. Vous pouvez télécharger la version courante de l’application en cliquant sur ce lien.

Si vous souhaitez contribuer, vous êtes les bienvenus. Tout se passe via le git proposé par github. L’application est faite en Python et j’ai essayé de rendre le code le plus lisible possible. Si vous souhaitez effectuer des remontées de bugs ou me donner votre avis, vous pouvez le faire sur ce blog ou sur github.

En Avril, j’avais écrit un petit billet sur la génération de certificats OpenVPN par lots ce qui est bien pratique lorsqu’on doit en générer une quantité importante. J’ai à nouveau rencontré cette problématique mais dans un contexte légèrement différent. Sous Ubuntu Server 10.04, le jeu d’outils Easy-RSA d’OpenVPN n’utilisent plus OpenSSL directement mais utilisent pkitool qui ne semble être qu’un intermédiaire de simplification.

Du coup, le script donné précédemment n’est plus valable. Il a donc fallu trouver une parade assez simple mais non moins fonctionnelle. La solution adaptée à pkitool ne tient plus qu’en un seul script qui est le suivant.

#! /bin/bash

# Make a certificate/private key pair using a locally generated

# root certificate.

export EASY_RSA= »`pwd` »

export OPENSSL= »openssl »

export PKCS11TOOL= »pkcs11-tool »

export GREP= »grep »

export KEY_CONFIG=`$EASY_RSA/whichopensslcnf $EASY_RSA`

export KEY_DIR= »$EASY_RSA/keys »

export PKCS11_PIN= »dummy »

export KEY_SIZE=1024

export CA_EXPIRE=3650

export KEY_EXPIRE=3650

export KEY_COUNTRY= »FR »

export KEY_PROVINCE= »FR »

export KEY_CITY= »Paris »

export KEY_ORG= »Antoine-Corp »

export KEY_EMAIL= »me@myhost.mydomain »

export KEY_CNAME=$1

export EASY_RSA= »${EASY_RSA:-.} »

« $EASY_RSA/pkitool » $*

Le tour est joué ! Vu que WordPress (ou plutôt de ces modules/thèmes) remplace les quotes par des guillemets impossibles à copier/coller dans un shell, je vous mets à disposition une version en texte brut jusqu’à ce que j’ai réussi à résoudre ce problème assez agaçant.

Au final, ce script devrait vous être utile pour générer rapidement des certifications OpenVPN à la pelle et ainsi vous simplifier la vie.