Mesurer le temps de réponse d'un site web#
Il peut être utile de mesurer le temps de réponse d'un site web, directement depuis le terminal. Voici quelques méthodes permettant de réaliser ces tests.
Au sommaire :
cURL#
cURL est un outil génial, qui permet, en ligne de commande, de transférer des données sur de nombreux protocoles (HTTP, HTTP/2, HTTP/3, FTP, SFTP, RTMP, etc.).
Installation de cURL#
Si vous ne l'avez pas encore installé, allons-y :
sudo apt install curlMesures avec cURL#
Maintenant on peut mesurer le temps de réponse d'un site web :
curl -o /dev/null -s -w "%{time_connect} + %{time_starttransfer} = %{time_total}\n" URL_À_TESTERtime_connect: Le temps, en secondes, qu'il a fallu pour que le protocole TCP se connecte au nom de domaine.time_starttransfer: Le temps, en secondes, qu'il a fallu avant le transfert du premier octet. Ce qui inclut le temps nécessaire au serveur pour préparer la réponse.time_total: Le temps total de la mesure, en secondes.
Par exemple, si je veux tester le temps de réponse du site https://caisse-solidarite.fr/, je lance :
curl -o /dev/null -s -w "%{time_connect} + %{time_starttransfer} = %{time_total}\n" https://caisse-solidarite.fr/Et ça me retourne :
0.052064 + 111.297523 = 111.422634Oula, pratiquement deux minutes (111 secondes) avant le premier transfert. Mais ce n'est pas étonnant, en cette journée de grève nationale du 23 Mars 2023, de nombreuses personne doivent être en train de soutenir les grévistes (ou alors le site se fait DoS).
Mesures avancées avec cURL#
Lors de notre mesure, on peut également afficher encore plus d'informations, en faisant par exemple :
curl -o /dev/null -s -w "\n \
namelookup: %{time_namelookup}s\n \
connect: %{time_connect}s\n \
appconnect: %{time_appconnect}s\n \
pretransfer: %{time_pretransfer}s\n \
redirect: %{time_redirect}s\n \
starttransfer: %{time_starttransfer}s\n \
-------------------------\n \
total: %{time_total}s\n" \
URL_À_TESTERtime_namelookup: Le temps, en secondes, qu'il a fallu pour résoudre le nom de domaine (c'est à dire la résolution du nom de domaine en adresse IP).time_connect: Le temps, en secondes, qu'il a fallu pour que le protocole TCP se connecte au nom de domaine.time_appconnect: Le temps, en secondes, qu'il a fallu pour l'établissement de la liaison sécurisée (SSL, SSH).time_pretransfer: Le temps, en secondes, qu'il a fallu pour initier le premier transfert. Ce qui inclut les négociations spécifiques au protocole.time_redirect: (optionnel) Le temps, en secondes, qu'il a fallu pour résoudre le nom de domaine, se connecter, initier le transfert de redirections.time_starttransfer: Le temps, en secondes, qu'il a fallu avant le transfert du premier octet. Ce qui inclut le temps nécessaire au serveur pour préparer la réponse.time_total: Le temps total de la mesure, en secondes.
Dans notre exemple, je lance un :
curl -o /dev/null -s -w "\n \
namelookup: %{time_namelookup}s\n \
connect: %{time_connect}s\n \
appconnect: %{time_appconnect}s\n \
pretransfer: %{time_pretransfer}s\n \
redirect: %{time_redirect}s\n \
starttransfer: %{time_starttransfer}s\n \
-------------------------\n \
total: %{time_total}s\n" \
https://caisse-solidarite.frCe qui me retourne, en ce jeudi noir :
namelookup: 0.023426s
connect: 0.047286s
appconnect: 0.167965s
pretransfer: 0.168024s
redirect: 0.000000s
starttransfer: 127.972907s
-------------------------
total: 128.117317sOn voit bien qu'il faut un temps considérable (127 secondes), au serveur web hébergeant caisse-solidarite.fr, pour préparer et transférer la réponse.
À titre de comparaison, je lance la même commande sur https://google.fr, ce qui me retourne :
namelookup: 0.043273s
connect: 0.063028s
appconnect: 0.258498s
pretransfer: 0.258833s
redirect: 0.000000s
starttransfer: 0.287419s
-------------------------
total: 0.287597sBien entendu, pour connaître les autres possibilités offertes par cURL, n'hésitez pas à lancer un petit man curl.
Apache#
Le serveur web Apache propose aussi un outil fort pratique appelé "ApacheBench".
Installation de Apache Bench#
Pour l'installer, on peut faire un :
sudo apt install apache2-utilsUtilisation de Apache Bench#
Pour lancer un test simple :
ab URL_À_TESTERExemple :
ab https://caisse-solidarite.fr/Ce qui me retourne.. déjà pas mal d'informations, jugez plutôt :
This is ApacheBench, Version 2.3 <$Revision: 1879490 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking caisse-solidarite.fr (be patient).....done
Server Software: Apache
Server Hostname: caisse-solidarite.fr
Server Port: 443
SSL/TLS Protocol: TLSv1.2,ECDHE-ECDSA-AES256-GCM-SHA384,256,256
Server Temp Key: X25519 253 bits
TLS Server Name: caisse-solidarite.fr
Document Path: /
Document Length: 136199 bytes
Concurrency Level: 1
Time taken for tests: 0.294 seconds
Complete requests: 1
Failed requests: 0
Total transferred: 136399 bytes
HTML transferred: 136199 bytes
Requests per second: 3.40 [#/sec] (mean)
Time per request: 294.123 [ms] (mean)
Time per request: 294.123 [ms] (mean, across all concurrent requests)
Transfer rate: 452.88 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 70 70 0.0 70 70
Processing: 224 224 0.0 224 224
Waiting: 140 140 0.0 140 140
Total: 294 294 0.0 294 294Utilisation avancée de Apache Bench#
Voici quelques options découvertes en faisant un man ab :
-n: nombre de requêtes à effectuer pour la session de benchmarking. Le défaut est de n'effectuer qu'une seule requête, ce qui conduit à des résultats non représentatifs.-c: nombre de requêtes multiples à exécuter à la fois. La valeur par défaut est une demande à la fois.
Attention : faire attention lorsqu'on joue avec ces paramètres, on peut vite provoquer, justement, une attaque de type DoS si nous faisons trop de demandes en même temps ! À manier avec prudence, donc.
Crédits#
La photo "Crowd down Stockton street" de Niall Kennedy est sous licence CC BY-NC 2.0.