Réaliser des tests de performances avec HTTPerf

Dans le développement ou la mise en production d’un site web ou d’une application web, il est important d’effectuer des tests de performances et c’est ce que nous propose HTTPerf !

HTTPerf, qu’est-ce que c’est ?

C’est un outil open source permettant de réaliser des tests de performances (benchmark en anglais) et plus précisément des tests de charge. Lorsque l’on déploie son site en production, il peut être intéressant de tester son serveur avec différents tests.

HTTPerf, comment ça fonctionne ?

Son fonctionnement est très simple et c’est pour ça que je vous le présente. Dans le monde du Load Testing (tests de charge) il y a plusieurs types de tests.

Ici, HTTPerf se contente d’envoyer un grand nombre de requêtes HTTP au serveur web cible et compte le nombre de réponses. C’est une des manières de mesurer la capacité d’encaissement de charge d’un serveur.

Le but est donc simple, on lance de nombreuses requêtes sur une URL et on augmente petit à petit la charge pour voir à partir de quand le taux de réponses n’est plus de 100% (ce qui désigne un taux de disponibilité idéal d’un serveur). Alors on connait le nombre de connexion HTTP maximum que notre serveur peut encaisser.

Comment installer HTTPerf ?

Je ne peux pas vous donner les méthodes d’installations pour chaque OS mais j’ai installé HTTPerf sur Debian et Windows.

Pour Debian (et Ubuntu) :

sudo apt-get install httperf

Pour Windows :

J’ai trouvé ce lien : https://itefix.net/httperf

Pour les autres :

Voici le lien du Github : https://github.com/httperf/httperf
Un lien Github c’est toujours pratique et si l’installation sur Debian ou Windows ne se passe pas bien, vous pouvez toujours compiler le programme en partant des sources.

HTTPerf, comment l’utiliser ?

Je vais utiliser HTTPerf sur ma machine Debian, mais vous devriez pouvoir suivre.
Comme d’habitude, je ne suis pas là pour vous donner un tutoriel complet sur cet outil mais un avant-goût afin de vous donner envie de d’aller plus loin avec cet outil.

Test de charge basique

Disclaimer : il est interdit d’effectuer ces tests sur des serveurs qui ne vous appartiennent pas. Pour faire le test sur votre hébergeur par exemple, demandez l’autorisation auparavant, on est jamais trop prudent. Ici, tous les tests seront fait sur mon serveur web local, mais rien ne vous empêche de monter un petit serveur sur une Raspberry pour qu’il y ait plus d’intérêt.

httperf --server localhost --port 80 --uri / --num-conns 10000

httperf désigne le nom du programme que j’utilise, l’argument –server permet de spécifier le nom d’hôte cible. À noter que, par défaut, il utilise comme valeur « localhost ». Dans notre cas, le préciser n’est donc pas indispensable.

L’argument –port est assez explicite, il permet de définir le port à utiliser. Par défaut, le porte utilisé est 80, donc il n’est pas nécessaire de le préciser non plus.

L’argument –uri permet de préciser sur quelle ressource on veut effectuer le test de charge, par exemple « /index.html ». Ici, je souhaite accéder à la racine, c’est-à-dire http://localhost/

Et pour finir, l’argument –num-conns qui définit le nombre de connexion à effectuer.

Le retour de cette commande dans mon cas est :

httperf --client=0/1 --server=localhost --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=10000 --num-calls=1
httperf: warning: open file limit > FD_SETSIZE; limiting max. # of open files to FD_SETSIZE
Maximum connect burst length: 1
Total: connections 10000 requests 10000 replies 10000 test-duration 11.865 s
Connection rate: 842.8 conn/s (1.2 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 0.7 avg 1.2 max 8.7 median 1.5 stddev 0.3
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000
Request rate: 842.8 req/s (1.2 ms/req)
Request size [B]: 62.0
Reply rate [replies/s]: min 840.5 avg 846.7 max 852.9 stddev 8.8 (2 samples)
Reply time [ms]: response 1.1 transfer 0.0
Reply size [B]: header 172.0 content 2567.0 footer 0.0 (total 2739.0)
Reply status: 1xx=0 2xx=10000 3xx=0 4xx=0 5xx=0
CPU time [s]: user 5.02 system 6.84 (user 42.3% system 57.6% total 100.0%)
Net I/O: 2305.4 KB/s (18.9*10^6 bps)
Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Bien que toutes les informations soient intéressantes, voilà les valeurs clés :

– Sur 10000 requêtes nous avons eu 10000 réponses
– Le test à duré 11.865 s
– Nous avons effectué 842.8 connexions par seconde et donc 842.8 requêtes
– Il n’y a eu aucune erreur

Test de charge avancé

Comme dit précédemment, le but est de connaître les limites de notre serveur. Il existe donc quelques arguments supplémentaires pour découvrir le test de charge maximum.

httperf --server localhost --port 80 --uri / --num-conns 10000 --rate 500 --hog --timeout 5

Cette commande n’est pas la plus compliquée, mais elle permet de jouer avec plus de paramètres.

L’argument –rate définit le nombre de requêtes que l’on souhaite effectuer en par seconde. À noter que si votre machine n’arrive pas à faire plus de 800 requêtes/s, il ne sert à rien de définir un –rate de 900.

L’argument –hog permet d’ouvrir le plus de ports TCP possible. Sans cette option, l’intervalle de ports disponibles sont de 1024 à 5000. Pour un vrai test, il est recommandé d’utiliser cet argument.

Pour finir, l’argument –timeout permet de définir le nombre de seconde avant de considérer la requête comme « sans réponse ». Par défaut, le –timeout est à 5, donc il n’est pas indispensable de la préciser dans notre cas.

HTTPerf, conclusion

Pour conclure, HTTPerf est un outil très basique et c’est ce qui m’a fait tombé sous son charme.
Je vous invite à lire le manuel d’utilisation complet (https://itefix.net/httperf-man-page) pour voir que, malgré une présentation simple, celui-ci peut prendre d’autres arguments afin de faire plus de choses.

Pour ceux qui souhaite effectuer encore plus de tests de charge et de benchmarking, sachez que HTTPerf n’est pas suffisant. Il y a pleins d’autres manières d’effectuer des tests et j’espère pouvoir en parler bientôt, comme des tests de stress longue durer pour voir s’il n’y a pas des fuites de mémoire ou autre. Aussi, beaucoup de sites interagissent avec l’utilisateur, il faut donc effectuer des tests avec plus d’interactions (login, upload de contenu, etc).

Ressource pour build httperf : https://easyengine.io/tutorials/benchmark/httperf/

Amusez-vous bien !

Safecode