Mon blog

J'ai eu récemment à tester un service REST, pour ses performances mais aussi pour sa robustesse, et ça a été l'occasion de faire un rapide tour des outils libres existants. Voici quelques notes.

Précisons bien le cahier des charges : le service à tester était du REST. Certes, il tournait sur HTTP mais ce n'était pas un site Web avec plein de traqueurs, de JavaScript, de vidéos ou de fenêtres polichinelles à faire disparaitre avant de voir quelque chose. Il n'utilisait que HTTP 1.1, je n'ai donc pas regardé ce que ces outils donnaient avec HTTP/2. Et je voulais des outils libres, fonctionnant autant que possible en ligne de commande.

On peut tester les performances d'un serveur HTTP simplement avec curl (et sa très pratique option --write-out) mais on voudrait ici des tests répétés, qui matraquent le serveur.

J'ai trouvé six outils différents, et voici mon expérience. Mais d'abord quelques notes générales si vous n'avez pas l'habitude de ce genre d'outils de test :

• Les résultats dépendent évidemment du réseau entre le client (le logiciel de test) et le serveur testé. On obtient évidemment des meilleures performances lorsqu'ils sont sur la même machine, mais c'est moins réaliste. Dans mon cas, le testeur était chez Free et le testé sur Nua.ge, ce qui veut dire entre autres que je ne maitrisais pas complètement les fluctations du réseau. (Mais j'ai aussi fait des tests en local.)
• Le parallélisme compte : une machine même lente peut saturer un serveur HTTP si elle fait de nombreuses requêtes en parallèle. Typiquement, le nombre de requêtes par seconde augmente lorsqu'on augmente le parallélisme, puis diminue au-delà d'un certain seuil.
• Pour atteindre un bon niveau de parallélisme, le client de test doit ouvrir beaucoup de fichiers (en fait, de descripteurs de fichiers), et des erreurs comme « socket: Too many open files (24) » seront fréquentes. Sur Unix, vous pouvez augmenter la limite du nombre de descripteurs ouverts avec limit descriptors 65535 (mais attention, cela va dépendre de plusieurs choses, options du noyau, être root ou pas, etc). Comme le dit un message du logiciel Locust  « It's [la limite] not high enough for load testing, and the OS didn't allow locust to increase it by itself. ». Les différents logiciels de test ont souvent une section entière de leurs documentation dédiée à ce problème (voir par exemple celle de Locust ou bien celle de Gatling).
• Le goulet d'étranglement qui empêche d'avoir davantage de requêtes par seconde peut parfaitement être dans la machine de test, trop lente ou mal connectée. (C'est pour cela qu'il est sans doute préférable que les programmes de test soient écrits dans un langage de bas niveau.)
• Même avec la plus rapide des machines et le meilleur programme de test, une seule machine peut être insuffisante pour tester une charge importante du serveur. Plusieurs logiciels de test ont un mécanisme pour répartir le programme de test sur plusieurs machines (voir par exemple dans la documentation de Locust).
• Enfin, d'une manière générale, la mesure de performances est un art difficile et il y a plein de pièges. Au minimum, quand vous publiez des résultats, indiquez bien comment ils ont été obtenus (dire « le serveur X peut traiter N requêtes/seconde » sans autre détail n'a aucune valeur).

Maintenant, les différents outils. On commence par le vénérable ApacheBench (alias ab). Largement disponible, son utilisation de base est :

ab -n 5000 -c 100 http://tested.example.org/
  

Le -n permet de spécifier le nombre de requêtes à faire et le -c le nombre de requêtes en parallèle. ApacheBench produit un rapport détaillé :

Time taken for tests:   8.536 seconds
Complete requests:      5000
Failed requests:        0
Requests per second:    585.74 [#/sec] (mean)
Time per request:       170.724 [ms] (mean)
Time per request:       1.707 [ms] (mean, across all concurrent requests)

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        5   93 278.9     39    3106
Processing:     5   65 120.1     43    1808
Waiting:        4   64 120.2     43    1808
Total:         14  158 307.9     87    3454

Percentage of the requests served within a certain time (ms)
  50%     87
  66%    104
  75%    123
  80%    130
  90%    247
  95%   1027
  98%   1122
  99%   1321
 100%   3454 (longest request)
  

Le serveur a bien tenu, aucune connexion n'a échoué. D'autre part, on voit une forte dispersion des temps de réponse (on passe par l'Internet, ça va et ça vient ; en local - sur la même machine, la dispersion est bien plus faible). Le taux de requêtes obtenu (586 requêtes par seconde) dépend fortement du parallélisme. Avec -c 1, on n'atteint que 81 requêtes/seconde.

ab affiche des messages d'erreur dès que le serveur HTTP en face se comporte mal, par exemple en fermant la connexion tout de suite (« apr_socket_recv: Connection reset by peer (104) » ou bien « apr_pollset_poll: The timeout specified has expired (70007) » et, dans ces cas, n'affiche pas du tout les statistiques. Ce manque de robustesse est regrettable pour un logiciel qui doit justement pousser les serveurs à leurs limites.

Par défaut, ab ne réutilise pas les connexions HTTP. Si on veut des connexions persistentes, il existe une option -k.

Deuxième logiciel testé, Siege (j'en profite pour placer le mot de poliorcétique, que j'adore) :

%  siege -c 100 -r 50 http://tested.example.org/ 
Transactions:		        5000 hits
Availability:		      100.00 %
Elapsed time:		        5.09 secs
Response time:		        0.07 secs
Transaction rate:	      982.32 trans/sec
Concurrency:		       66.82
Successful transactions:        5000
Failed transactions:	           0
Longest transaction:	        3.05
Shortest transaction:	        0.00

(Le nombre de requêtes, donné avec -r est par fil d'exécution et non pas global comme avec ab. Ici, 50*100 nous redonne 5 000 comme dans le test avec ab.) On voit qu'on a même pu obtenir un taux de requêtes plus élevé qu'avec ab alors que, comme lui, il crée par défaut une nouvelle connexion HTTP par requête. En éditant le fichier de configuration pour mettre connection = keep-alive (pas trouvé d'option sur la ligne de commande pour cela), on obtient cinq fois mieux :

Transactions:		        5000 hits
Availability:		      100.00 %
Elapsed time:		        0.92 secs
Response time:		        0.02 secs
Transaction rate:	     5434.78 trans/sec
Concurrency:		       85.12
Successful transactions:        5000
Failed transactions:	           0
Longest transaction:	        0.46
Shortest transaction:	        0.00

Si vous augmentez le niveau de parallélisme, vous aurez peut-être le message d'erreur :

WARNING: The number of users is capped at 255.  To increase this
         limit, search your .siegerc file for 'limit' and change
         its value. Make sure you read the instructions there...
  

Il faut alors éditer le fichier de configuration (qui ne s'appelle pas .siegerc, sur ma machine, c'était ~/.siege/siege.conf) et changer la valeur. (Rappelez-vous l'avertissement au début sur les limites imposées par le système d'exploitation.)

Siege a aussi des problèmes de robustesse et vous sort des messages comme « [alert] socket: select and discovered it's not ready sock.c:351: Connection timed out » ou « [alert] socket: read check timed out(30) sock.c:240: Connection timed out ».

Notons que Siege permet d'analyser le HTML reçu et de lancer des requêtes pour les objets qu'il contient, comme le CSS, mais je n'ai pas essayé (rappelez-vous, je testais un service REST, pas un site Web).

Troisième logiciel testé, JMeter. Contrairement à ApacheBench et Siege où tout était sur la ligne de commande et où on pouvait démarrer tout de suite, JMeter nécessite de d'abord définir un Test Plan, listant les requêtes qui seront faites. Cela permet de tester Et, apparemment, on ne peut écrire ce plan qu'avec l'outil graphique de JMeter (« GUI mode should only be used for creating the test script, CLI mode (NON GUI) must be used for load testing »). J'étais de mauvaise humeur, je ne suis pas allé plus loin.

Quatrième logiciel, Cassowary. Contrairement aux trois précédents, il n'était pas en paquetage tout fait pour mon système d'exploitation (Debian), donc place à la compilation. Cassowary est écrit en Go et la documentation disait qu'il fallait au moins la version 1.15 du compilateur mais, apparemment, ça marche avec la 1.13.8 que j'avais :

git clone https://github.com/rogerwelin/cassowary.git
cd cassowary 
go build ./cmd/cassowary   
  

Et on y va :

% ./cassowary run -u http://tested.example.org/   -n 5000 -c 100    

 TCP Connect.....................: Avg/mean=17.39ms 	Median=16.00ms	p(95)=36.00ms
 Server Processing...............: Avg/mean=15.27ms 	Median=13.00ms	p(95)=22.00ms
 Content Transfer................: Avg/mean=0.02ms 	Median=0.00ms	p(95)=0.00ms

Summary: 
 Total Req.......................: 5000
 Failed Req......................: 0
 DNS Lookup......................: 8.00ms
 Req/s...........................: 5903.26
  

Par défaut, Cassowary réutilise les connexions HTTP, d'où le taux de requêtes élevé (on peut changer ce comportement avec --disable-keep-alive). Lui aussi affiche de vilains messages d'erreur (« net/http: request canceled (Client.Timeout exceeded while awaiting headers) ») si le serveur HTTP, ayant du mal à répondre, laisse tomber certaines requêtes. Et, ce qui est plus grave, Cassowary n'affiche pas les statistiques s'il y a eu ne serait-ce qu'une erreur.

Cinquième logiciel utilisé, k6. Également écrit en Go, je n'ai pas réussi à le compiler :

% go get go.k6.io/k6 
package hash/maphash: unrecognized import path "hash/maphash" (import path does not begin with hostname)
package embed: unrecognized import path "embed" (import path does not begin with hostname)

Les deux derniers logiciels sont, je crois, les plus riches et aussi les plus complexes. D'abord, le sixième que j'ai testé, Gatling. On le télécharge, on unzip gatling-charts-highcharts-bundle-3.7.3-bundle.zip et on va dans le répertoire ainsi créé. On doit d'abord enregistrer les tests à faire. Pour cela, on lance l'enregistreur de Gatling. L'interface principale est graphique (je n'ai pas vu s'il y avait une interface en ligne de commande) :

%  ./bin/recorder.sh

Il fait tourner un relais HTTP qu'on doit ensuite utiliser depuis son client HTTP. Par exemple, si j'utilise curl :

% export http_proxy=http://localhost:8000/
% curl http://tested.example.org/

Et Gatling enregistrera une requête HTTP vers http://tested.example.org/. Le plan est écrit sous forme d'un programme Scala (d'autres langages sont possibles) que Gatling exécutera. Il se lance avec :

% ./bin/gatling.sh
  

Et on a une jolie page HTML de résultats. Après, les choses se compliquent, Gatling est très riche, mais il faut écrire du code, même pour une tâche aussi simple que de répéter une opération N fois.

Enfin, le septième et dernier, Locust. (Après le champ lexical de la guerre, avec Siege et Gatling, celui d'une plaie d'Égypte…) Locust est écrit en Python et il a été simple à installer avec pip3 install locust. Il dispose d'une documentation détaillée. Comme JMeter, il faut écrire un plan de test mais, contrairement à JMeter, on peut le faire avec un éditeur ordinaire. Ce plan est écrit lui-même en Python et voici un exemple très simple où le test sollicitera deux chemins sur le serveur :

from locust import HttpUser, task
import requests

class HelloWorldUser(HttpUser):
        @task
        def hello_world(self):
            self.client.get("/")
            self.client.get("/hello")
  

Une fois le plan écrit, on peut lancer Locust en ligne de commande :

% locust --host http://tested.example.org --headless --users 100 --spawn 10
  

On ne peut pas indiquer le nombre maximal de requêtes (seulement le temps maximal), il faut interrompre le programme au bout d'un moment. Il affiche alors :

  Name                                                              # reqs      # fails  |     Avg     Min     Max  Median  |   req/s failures/s
------------------------------------------------------------------------------------------------------------------------------------------------
 GET /                                                              20666     0(0.00%)  |      87       7     541      94  |  736.70    0.00
  

On voit que le nombre de requêtes par seconde est faible. Une des raisons est que Locust est très consommateur de temps de processeur : celui-ci est occupé à 100 % pendant l'exécution, et est le facteur limitant. Locust avertit, d'ailleurs, « CPU usage above 90%! This may constrain your throughput and may even give inconsistent response time measurements!  ». Bref, il ne pousse pas le serveur à ses limites. Locust réutilise les connexions HTTP, et je n'ai pas trouvé comment faire si on voulait tester sans cela. Cette réponse sur StackOverflow ne marche pas pour moi, les requêtes sont bien faites, mais pas comptées dans les statistiques.

Mais l'intérêt de Locust est de lancer un serveur Web qui permet d'obtenir de jolis graphes :

On peut aussi utiliser cette interface Web pour piloter les tests.

En conclusion ? Je ne crois pas qu'il y ait un de ces logiciels qui fasse tout ce que je voulais et comme je voulais. Donc, j'en garde plusieurs.