Au départ prévue pour stocker des liens que je jugeais intéressants, la revue de presse hebdomadaire me permet de partager mes découvertes avec vous. Pour cette 66ème édition : des titres de jobs ridicules, des noms de réseaux Wifi originaux, des hacks un peu flippants, une chouette vidéo sur une réaction en chaîne, et des conseils pour bien nettoyer son capteur et ses objectifs photos.
J’ai déjà abordé à 3 reprises les tests de montée en charge pour des sites ou des applications web :
La semaine dernière, j’ai découvert presque caché dans le panier du libre de Nicolargo un nouveau concurrent : Blitz.io, et là….tadaaaa ! 
Complètement développé en node.js, Blitz.io vous propose des tests de performances, ainsi que des tests de montée en charge pour votre site, application web, ou API RESTful. Blitz.io apporte beaucoup de fraîcheur dans l’écosystème des tests de performances.
Un test de performance simple sur Blitz.io
Dans la jungle des techniques d’optimisation d’un serveur web, si vous avez une application ou un site/blog en PHP5, il existe une solution relativement simple à mettre en place : APC (pour Alternative PHP Cache).
Disponible sous forme de package PECL (PHP Extension Community Library), APC fait parti de ce que l’on nomme les « accélérateurs PHP ». Il en existe plusieurs autres :
J’ai choisi APC pour sa facilité d’installation, mais également pour sa future intégration dans PHP 5.4 (puisque la version 6 est annulée jusqu’à nouvel ordre).
Son fonctionnement est simple : APC est un cache d’OPCode. Le code qui est lisible par un humain doit être transformé en code lisible par une machine : dans le cas de PHP, ceci est fait à la volée, pour chaque exécution de fichier. APC intercepte la phase de compilation du code, et la remplace par du code déjà généré précédemment, qui avait été mis en mémoire. On économise ainsi une étape, et donc du traitement.
Cette technique est surtout utile avec l’utilisation de frameworks : en effet, le contenu des fichiers ne change pas en phase de production, la version en mémoire est donc toujours la bonne.
Avant de l’installer, je fais un benchmark avec ApacheBench, ce qui me permettra de faire une comparaison une fois le cache activé.
PHP & Apache Benchmark sans APC
Note : le test a été réalisé en local sur la page d’accueil d’un blog WordPress. Apache peut fournir ici 111 requêtes par serconde.
La dernière version stable au moment où j’écris cet article est la 3.1.6. Pour commencer, il faut installer les paquets « php-pear » et « php-devel » car PECL en a besoin. Une fois installés, il suffit d’y aller gaiement avec la commande « pecl install apc ».
Installation d'APC via PECL
Note : il se peut que l’installation pose une ou deux questions. Si vous ne savez pas, laissez les valeurs par défaut.
Il reste à activer APC pour qu’il soit chargé au lancement d’Apache. Il est possible d’ajouter la ligne suivante dans le php.ini :
extension=apc.so
Pour ma part, j’ai l’habitude de dissocier chaque fonction : j’utilise un fichier apc.ini qui charge APC, et qui contient les paramètres de configuration. Il se trouve dans /etc/php.d/
extension=apc.so
apc.shm_segments= »1″
apc.shm_size= »128″
apc.stat= »0″
apc.filters= »wp-admin »
La première ligne permet de charger l’extension, puis je déclare un segment de 128 Mo de cache. Le paramètre apc.stat positionné sur false indique qu’il ne faut pas vérifier si le code PHP a changé. Si vous êtes en phase de maquette/pré-production, vous pouvez le mettre sur 1, de telle façon qu’APC ira chercher quels fichiers sont modifiés depuis la dernière exécution.
Enfin, apc.filters me permet d’exclure le répertoire wp-admin de mon blog pour la mise en cache. Les paramètres seront pris en compte au prochain redémarrage d’Apache.
C’est le moment de refaire un benchmark pour voir le résultat :
PHP & Apache benchmark avec APC activé
Ici, on peut noter une différence relativement importante : 6 fois plus de requêtes simultanées possibles sur le même serveur. Ne vous réjouissez pas trop vite, cela dépend de pas mal de facteurs !
Il existe une interface web toute prête qui vous permettra de consulter les statistiques d’utilisation de votre/vos instance(s) APC. Il faut copier le fichier /usr/share/pear/apc.php dans un répertoire qui est publié par le serveur web. Voici le résultat :
Dashboard APC : statistiques et debug
Si vous voulez protéger l’accès à cette interface, il suffit d’éditer le fichier apc.php, et d’y modifier les identifiants par défaut :
Identifiants par défaut
A noter qu’il est tout à fait possible d’associer APC et Memcached sur le même serveur : les deux systèmes sont totalement différents et n’assurent pas les mêmes fonctionnalités.
La documentation du paramétrage d’APC se trouve sur la page : Runtime Configuration.
Après un court article d’introduction sur Memcached, je reviens sur son monitoring.
Pour rappel :
Memcached est un système de cache d’objets distribué et non répliqué. Il va stocker des objets en RAM, pour diminuer les temps de réponses des applications.
Chaque serveur Memcached démarre avec une certaine quantité de mémoire allouée. Comme le système est de type LRU (Least Recently Used), ce sont les données les plus anciennes qui seront supprimées une fois la limite de la mémoire atteinte. Et inversement, il n’est pas non plus judicieux d’allouer trop de RAM car la perte d’une instance Memcached entrainerait la perte des données stockées (si elle n’est pas protégée/répliquée).
Pour surveiller les serveurs Memcached, on peut jouer avec beaucoup d’outils / de scripts (templates Cacti, Nagios, etc.), mais il existe une solution dédiée au monitoring et au debugging de Memcached : phpmemcacheadmin.
Se présentant sous la forme de quelques fichiers PHP à déposer sur un serveur Web, on peut y ajouter et monitorer autant de serveurs Memcached que l’on souhaite.
On y retrouvera un tableau de bord avec divers statistiques :
Il est également possible de consulter des statistiques « live » par serveur surveillé.
Consultation "live" des statistiques
Enfin, il est possible de consulter les valeurs stockées via la page « Execute commands on Servers », et d’interagir avec : insertion, suppression, flush des données, etc.
Exécution de commandes via phpmemcacheadmin
Très bon complément de votre système de monitoring global, phpmemcacheadmin permet une vue plus complète de vos serveurs Memcached, pour une installation simplissime.
Parmi toutes les optimisations possibles pour un blog, un site ou une application, on retrouve Memcached qui se positionne comme un système de cache d’objets distribué et non répliqué. Initialement développé par Danga pour Livejournal, c’est un outil open source qui est maintenant utilisé par de nombreux sites (Facebook, Youtube, mon blog, Flickr, etc.)
J’utilise Memcached sur le serveur de mon blog depuis quelques mois, et la différence avec/sans est assez flagrante.
Pour comprendre son utilité, je rappelle simplement que les temps d’accès à la mémoire vive d’un serveur sont nettement supérieurs à ceux d’un disque (nanosecondes VS millisecondes, cad un ratio compris entre 10 000 et 100 000).
C’est là que Memcached intervient. Il va créer des tableaux de données en RAM : cela va contribuer à réduire le nombre de fois qu’une même donnée stockée sur un périphérique de stockage mécanique est lue.
La principale chose à comprendre avec Memcached est qu’il s’agit d’un système d’usage général, et que les applications doivent être « conscientes » de sa présence. Ce n’est pas quelque chose de magique, qu’il suffit d’installer pour multiplier les performances par 10. Il faudra a minima installer un plugin si vous utilisez un CMS, voire repasser dans une partie du code.
Sous forme d’architecture client-serveur, Memcached se présente comme un démon qui écoute par défaut sur le port 11211. Le système créé des tableaux dont les clés de 250 octets pointent vers des valeurs qui peuvent avoir jusqu’à 1 Mo (mégaoctet). Si la quantité de mémoire allouée est pleine, les clés les plus anciennes sont supprimées (méthode Least Recently Used). Comme les données sont stockées en RAM, elles seront perdues si le serveur redémarre.
Il est possibles d’utiliser plusieurs instances Memcached. Par exemple, une application ABC peut mettre des données en cache sur 3 serveurs différents :
Chaque serveur sera autonome et ne communiquera pas avec ses voisins.
Il est possible de répliquer des instances Memcached, mais ceci est une autre histoire !
Un grand nombre de librairies clientes pour accéder à Memcached sont disponibles : C/C++, PHP, Java, Windows/.Net, Ruby, Perl, etc.
Pour vérifier le gain de performances, j’ai utilisé un serveur de test, avec une installation de WordPress vierge. J’ai fait un test de charge avec ApacheBench, avec et sans Memcached activé.
Benchmark :
Nb : il s’agit d’une installation d’Apache2 avec un paramétrage par défaut sur une CentOS 5.5 32 bits, 1 vCPU 2 Ghz, 512 Mo de Ram.
En conclusion, Memcached est un élément non négligeable qu’il est bon d’intégrer dans la conception d’une application. Cependant, comme c’est une couche d’intégration supplémentaire, il faut faire en sorte que l’application soit consciente que système existe.
Je reviendrais plus tard sur l’installation de Memcached…
Lors d’installations ou de configurations de serveurs, on recherche souvent l’une ou l’autre informations sur les paramètres de PHP. Deux choix s’offrent à vous :
Pour ce deuxième cas, j’ai déjà vu des personnes faire de longues commandes du type :
echo « < ?php phpinfo()? > » | php
Pour, il existe une commande toute faite :
php -i
Afficher un phpinfo() en ligne de commande
D’autres astuces ?
Romain DECKER, 30 ans, ingénieur système, curieux, obstiné, passionné par les nouvelles technologies et leurs applications, je tiens ce blog depuis quelques années.
Vous pouvez également me suivre sur Twitter et sur Facebook via les boutons ci-dessous.