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.

De l’intérêt des tests de performances pour les applications en ligne ?

Les tests de performances hardware ne se comptent plus : tous les produits qui sortent sont testés, re-testés, encore et encore.

Pourtant, plus de 95% des éditeurs (de sites ou d’applications en ligne) ne pensent pas à faire des tests de performance, ou ne savent pas comment faire.

Or, il arrive que certains sites ne répondent plus lors de grosses affluences : ce phénomène s’appelle « Slashdot Effect« .

Slashdot effect : désigne le fait qu’un site internet soit submergé de requêtes provenant d’utilisateurs de Slashdot (ou Digg/Techcrunch) au moment de la publication d’une nouvelle le référençant, le rendant ainsi momentanément indisponible par déni de service (Wikipedia).

Vous vous souvenez de l’indisponibilité de Pownce ? Voilà un bon exemple d’un buzz qui a parfaitement fonctionné, mais d’une infrastructure qui ne tenait pas la route.

Un cauchemar, non ?
Vous lancez une application susceptible d’intéresser des milliers d’utilisateurs, vous buzzez autour, mais celle-ci est indisponible.

(suite…)