Performances HTTP

Lundi 22 août 2005 21:38 - Code

Le premier outil, pour mesurer le nombre de connexions possibles vers un site web, c'est ab, Apache Bench, qui vient comme son nom l'indique d'Apache. C'est pratique, ça donne pas mal d'informations, dans un rapport qui ressemble à ça:

Concurrency Level:      1
Time taken for tests:   30.3667 seconds
Complete requests:      5742
Failed requests:        0
Write errors:           0
Total transferred:      6799705 bytes
HTML transferred:       5151464 bytes
Requests per second:    191.38 [#/sec] (mean)
Time per request:       5.225 [ms] (mean)
Time per request:       5.225 [ms] (mean, across all concurrent requests)
Transfer rate:          221.31 [Kbytes/sec] received

(l'appel étant ici ab2 -t 30 http://site/forms/)

C'est nickel, ça permet d'écrire que « ce site peut gérer 200 requêtes par seconde » et basta.

Un autre outil, c'est httperf, ça fait un peu la même chose, httperf --hog --server=site --uri=/forms/ --num-conns=2000 donnera un rapport contenant:

Connection rate: 204.3 conn/s (4.9 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 4.6 avg 4.9 max 58.0 median 4.5 stddev 2.4
Connection time [ms]: connect 0.2
Connection length [replies/conn]: 1.000

Request rate: 204.3 req/s (4.9 ms/req)
Request size [B]: 60.0

Hop, ici aussi à peu près 200 requêtes par seconde, ça permet de confirmer.

Mais ce que tout le monde attend, c'est un dessin, tout le monde aime les dessins. Un dessin avec un point tapé à la gradation 200 d'une échelle, ça ne le fait pas trop, ce qu'il faut c'est un graphique montrant à quel point ça tient bien la charge.

Pour se faire, c'est facile, on teste 10 requêtes/seconde, ça tient ? On note que ça tient. On teste 20 req/s, ça tient ? On note. 30 req/s ? Noté. Ainsi de suite jusqu'au moment où ça sature. De ça on fait un dessin, une ligne qui monte puis qui se stabilise, au maximum de requêtes/seconde possibles.

Bien sûr, tester, noter, retester, renoter, ça prend du temps, ça peut être automatisé, autobench fait ça (pas de paquet Debian officiel, mais un paquet sur le site du programme). Ça produira un tableau, première colonne le nombre de requêtes/seconde testé, puis des colonnes de résultats, extrait ci-dessous, je n'ai gardé que la deuxième colonne, avec le nombre de requêtes/seconde effectivement réalisées:

dem_req_rate    actual_req_rate
25              25.1
50              50.2
75              75.2
100             100.2
125             125.2
150             150.1
175             175.0
200             196.7
225             203.9
250             187.8
275             196.1

Ça coince toujours aux alentours de 200 req/s, évidemment, mais ça permet maintenant de tracer une ligne. Génial.

Maintenant, ce qu'autobench peut faire aussi, c'est tester deux sites, et agréger les résultats dans un seul fichier, bien. Et autobench vient avec un script, bench2graph, qui permet de transformer les tableaux produits en jolis dessins.

Alors voilà, j'ai fait tout ça pour avoir le résultat suivant:

Custom Pickle Storage vs SQLObject with SQLite

Custom Pickle Storage (les lignes étiquetées ..._pickle), c'était un moyen artisanalement créé pour stocker les infos d'un site, utilisant le module cPickle de Python et quantité de fichiers.

SQLObject with SQLite, c'est deux choses, d'abord SQLObject qui est un object-relational mapper, c'est-à-dire quelque chose permettant de faire le lien entre les tables d'une base de données et les objets d'un programme, SQLite, c'est un moteur SQL, stockant toutes ses données dans un unique fichier, ne fonctionnant pas en mode client/serveur.

Pour diverses raisons, j'ai passé le week-end à remplacer la première méthode par la seconde. Elle sature presque deux fois plus tôt. Il y aurait peut-être des conclusions à tirer.

Dernière modification: lundi 22 août 2005 21:39