Test de montée en charge d’un site web ou d’une API avec Blitz.io

J’ai déjà abordé à 3 reprises les tests de montée en charge pour des sites ou des applications web :

  • via ApacheBench, à travers des commandes en ligne depuis un serveur,
  • avec LoadImpact, qui vous permet de tester des montées en charge sur des sites ou applications jusqu’à 50 utilisateurs simultanés gratuitement.

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

Un test de performance simple sur Blitz.io

(suite…)

Boostez les performances PHP avec APC

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 :

  • eAccelerator,
  • XCache,
  • Turk MMCache (plus maintenu),
  • etc.

Logo APCJ’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

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.

Installation d’APC

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

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.

Configuration

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é

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 ! :)

Interface d’administration

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

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 :

APC : 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.

Optimisez les performances de votre site avec Memcached

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.

Memcached : système de mise en cache d'objets

Logo MemcachedPour 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 :

  • memcached1.monappli.com
  • memcached2.monappli.com
  • memcached3.monappli.com

Chaque serveur sera autonome et ne communiquera pas avec ses voisins.

Architecture Memcached : isolation des serveurs

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.

Performances : avec / sans Memcached sur un WordPress

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 :

  • WordPress sans Memcached : 8,75 requêtes / secondes,
  • WordPress avec Memcached : 150 requêtes / secondes.

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…

Comment Facebook gère quotidiennement son infrastructure

Facebook est une vraie machine de guerre : on a pu voir récemment que c’était le site le plus visité au monde, et tout ça seulement après quelques années. Contrairement à d’autres « supergrands » (Google, Microsoft, Apple, Youtube, etc.) un certain nombre d’informations filtrent lors de conférences, et dans des documents officiels.

Logo Facebook

Je rappelle que pour écrire ces 2 articles, j’ai simplement visionné des vidéos de conférences pour compiler les informations. Vu la masse de détails obtenus, j’ai publié deux articles :

En extrapolant plusieurs données (graphiques d’évolution, chiffres passés, etc.) on estime entre 60 000 et 100 000 le nombre de serveurs de Facebook .

Facebook : évolution du nombre de serveurs

Facebook : évolution du nombre de serveurs

Cependant, ce chiffre ne tient pas compte de deux nouveaux datacenters actuellement en cours construction (Oregon et Caroline du Nord).

Facebook a depuis longtemps atteint une masse critique qui nécessite de voir sa copie en terme d’administration quotidienne.

Un des ingénieurs de Facebook a bien illustré le problème lors d’une conférence :

With Facebook users spending a collective 8 billion minutes on the site each day, serving 1.2 million photos each second, and managing more than 25 terabytes of data per day in logging data, we’re forced to think about servers and datacenters differently.

Nb : les chiffres sont de 2009, les actuels sont présents dans mon article précédent.

(suite…)

L’infrastructure de Facebook : les chiffres clés

Facebook est une vraie machine de guerre : on a pu voir récemment que c’était le site le plus visité au monde, et tout ça seulement après quelques années. Contrairement à d’autres « supergrands » (Google, Microsoft, Apple, Youtube, etc.) un certain nombre d’informations filtrent lors de conférences, et dans des documents officiels.

Logo Facebook

J’ai visionné plusieurs heures de vidéos de conférences (long mais super intéressant) et ait compilé les informations. Vu la masse de détails obtenus, j’ai décidé de publier deux articles :



En extrapolant

  • certains graphiques d’évolution,
  • des chiffres passés,
  • des indications fournies pendant des conférences,

on estime entre 60 000 et 100 000 le nombre de serveurs de Facebook . Cependant, ce chiffre ne tient pas compte de deux nouveaux datacenters actuellement en cours construction (Oregon et Caroline du Nord).

Facebook : évolution du nombre de serveurs

Facebook : évolution du nombre de serveurs

Mais qu’est-ce qui peut bien tourner sur cette infrastructure ? :)

Données générales :

  • 500 millions d’utilisateurs actifs (un utilisateur actif est un utilisateur qui se connecte au moins une fois par mois),
  • 50% des utilisateurs se connectent au moins une fois par jour, soit 250 millions de personnes tout de même,
  • 690 milliards de pages vues par mois,
  • 6 milliards de contenus partagés par semaine (statuts, photos, liens, vidéos),
  • 3 milliards de photos uploadées par mois, pour plus d’un pétaoctet de stockage uniquement destiné aux photos (chaque photo existe en 4 tailles),
  • un dernier chiffre, le plus parlant peut-être : 16 milliards de minutes sont passées par jour sur Facebook. Ça représente 11 millions de jours ou encore plus de 30 000 années qui sont passées par jour sur le réseau social, c’est juste énorme !

Données techniques :

  • plus de 300 To (téraoctets) de données en cache en RAM avec Memcached,
  • 25 To (téraoctets) de log par jour,
  • un ingénieur Facebook pour 1,1 millions d’utilisateurs. A titre de comparaison, Google emploi un ingénieur pour 190 000 utilisateurs,
  • un opérateur Facebook pour 2,3 millions d’utilisateurs.

Quelques chiffres intéressants sur MySQL :

  • 13 millions de requêtes par seconde en pic,
  • 38 Go/s de trafic MySQL en pic,
  • temps de réponse moyen en lecture : 4 ms,
  • temps de réponse moyen en écriture : 5 ms,
  • 450 millions de lignes lues par seconde en pic,
  • 3,5 millions de lignes modifiées par seconde en pic,
  • 5,2 millions d’I/O (disques) InnoDB par seconde.

Qui a d’autres chiffres intéressants et récents à partager ? :)

Dans le prochain article sur le sujet, je traiterai de la gestion quotidienne d’une infrastructure de cette taille.

Sources :

Benchmarkez votre serveur avec ApacheBench

Vous aimez jouer avec les paramètres de votre serveur web (Apache, lighttpd, Nginx, etc.) ou avec votre code source, mais comment savoir si cela a un impact négatif ou positif sur les performances ?

Avant d’entrer dans le vif du sujet, je tenais à préciser que le benchmarking d’une application web ou d’un serveur est une tâche complexe : il ne faut pas penser arriver avec une commande toute prête qui vous donnera un chiffre magique. Il faut comprendre où peuvent se situer les goulots d’étranglements, comprendre le design global, etc.

Logo Apache

La fondation Apache a intégré un outil dans son programme : « Apache HTTP server benchmarking tool« , plus communément appelé « Apachebench » (ou encore « ab« ), qui vous permet de savoir combien de requêtes par seconde votre installation est capable de fournir.

Ce qu’il est possible de faire avec Apachebench : simuler du traffic en générant des requêtes HTTP.

Ce qu’il n’est pas possible de faire avec Apachebench : simuler le comportement d’un utilisateur qui visite un site/une application.

Pour installer Apachebench sur Debian/Ubuntu :

$ sudo aptitude install apache2-utils

Pour installer Apachebench sur Red Hat / CentOS : le programme « ab » est installé avec Apache. Pour ceux qui n’ont pas Apache installé :

# yum install httpd

La documentation, et sinon un « man ab » permettra de vous donner rapidement les différents paramètres. Par exemple, pour tester mon blog j’utilise les paramètres suivants :

# ab -t30 -c5 http://www.woueb.net/

  • -t : représente la durée du test, soit 30 secondes
  • -c : indique le nombre de requêtes concurrentes (simultanées) à utiliser

Voici le résultat sur mon serveur : la valeur la plus importante (entourée en rouge) est le nombre de requêtes par seconde qu’à pu supporter le serveur.

Résultat d'Apache Benchmark pour woueb.net

Dans cet exemple, Apachebench va uniquement charger le contenu de la page d’accueil de mon blog (textes, contenus et code html) sans appels extérieurs (images, CSS, Javascript, etc.). J’insiste sur le faire que ce n’est pas représentatif de l’utilisation d’un visiteur normal.

En précisant le paramètre « -w« , le résultat est exporté dans un tableau HTML.

Résultat d'Apache Benchmark pour woueb.net en HTML

Résultat d'Apache Benchmark pour woueb.net en HTML

Sinon, un « man ab » vous donnera également un aperçu de la documentation.

Deux types de tests :

  • test en local : permet de tester le nombre maximum de requêtes par secondes que le système peut fournir, sans tenir compte de la bande passante.
  • test à partir d’un serveur distant : pour tester en « conditions réelles » avec l’influence de la bande passante. Dans ce cas, il est intéressant de prévoir plusieurs tests simultanés et de tenir compte de la bande passante sortante du serveur à partir duquel la commande est lancée.

Quelques conseils :

  • ayez une bonne alimentation,
  • essayez d’avoir une bonne bande passante entre le serveur testé et le serveur destination,
  • relevez la charge de votre serveur web avant, pendant et après le test (CPU, Ram, nombre de processus, load, etc.),
  • testez plusieurs pages de votre site/application,
  • ne vous contentez pas d’un seul test : faites plusieurs tests d’affilé, ou à différents moments de la journée, et calculez les moyennes.

ApacheBench est donc un outil basique mais qui permet notamment de se rendre compte d’une augmentation (ou d’une diminution) de performances suite à une modification de code, de configuration, de rajout matériel, etc.