Connaissez-vous le temps de réponse moyen de votre site Web ? Savez-vous combien d’utilisateurs simultanés votre site peut gérer ?
Les tests de charge sont essentiels pour que les applications Web connaissent la capacité du site Web. Si vous devez choisir le serveur Web, l’une des premières choses à faire est d’effectuer le test de charge et de voir lequel fonctionne le mieux pour vous.
L’analyse comparative peut vous aider à décider;
- Quel serveur Web fonctionne le mieux
- Nombre de serveurs dont vous avez besoin pour servir x nombre de requêtes
- Quelle configuration vous donne les meilleurs résultats
- Quelles piles technologiques fonctionnent le mieux
- Quand votre site fonctionnera plus lentement ou tombera en panne
Il existe plusieurs outils en ligne pour effectuer un test d’effort ; Cependant, si vous recherchez une solution interne ou si vous souhaitez évaluer uniquement les performances du serveur Web, vous pouvez utiliser ApacheBench et, en alternative, certains des outils répertoriés ci-dessous.
J’ai utilisé le serveur Web Apache & Nginx hébergé sur DigitalOcean pour le tester.
Table des matières
ApacheBench
ApacheBench (ab) est un programme en ligne de commande open source qui fonctionne avec n’importe quel serveur Web. Dans cet article, je vais vous expliquer comment installer ce petit programme et effectuer le test de charge pour comparer les résultats.
apache
Installons ApacheBench à l’aide d’une commande yum.
yum install httpd-tools
Si vous avez déjà httpd-tools, vous pouvez l’ignorer.
Voyons maintenant comment il fonctionne pour 5000 requêtes avec une simultanéité de 500.
[[email protected] ~]# ab -n 5000 -c 500 http://localhost:80/ This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Completed 500 requests Completed 1000 requests Completed 1500 requests Completed 2000 requests Completed 2500 requests Completed 3000 requests Completed 3500 requests Completed 4000 requests Completed 4500 requests Completed 5000 requests Finished 5000 requests Server Software: Apache/2.2.15 Server Hostname: localhost Server Port: 80 Document Path: / Document Length: 4961 bytes Concurrency Level: 500 Time taken for tests: 13.389 seconds Complete requests: 5000 Failed requests: 0 Write errors: 0 Non-2xx responses: 5058 Total transferred: 26094222 bytes HTML transferred: 25092738 bytes Requests per second: 373.45 [#/sec] (mean) Time per request: 1338.866 [ms] (mean) Time per request: 2.678 [ms] (mean, across all concurrent requests) Transfer rate: 1903.30 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 42 20.8 41 1000 Processing: 0 428 2116.5 65 13310 Waiting: 0 416 2117.7 55 13303 Total: 51 470 2121.0 102 13378 Percentage of the requests served within a certain time (ms) 50% 102 66% 117 75% 130 80% 132 90% 149 95% 255 98% 13377 99% 13378 100% 13378 (longest request) [[email protected] ~]#
Ainsi, comme vous pouvez le voir, Apache a traité 373 requêtes par seconde et il a fallu un total de 13,389 secondes pour répondre au total des requêtes.
Vous savez maintenant que la configuration par défaut peut répondre à ces nombreuses demandes. Ainsi, lorsque vous apportez des modifications à la configuration, vous pouvez refaire le test pour comparer les résultats et choisir le meilleur.
Nginx
Faisons le test de ce que nous avons fait pour Apache afin que vous puissiez comparer celui qui fonctionne le mieux.
[[email protected] ~]# ab -n 5000 -c 500 http://localhost:80/ This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Completed 500 requests Completed 1000 requests Completed 1500 requests Completed 2000 requests Completed 2500 requests Completed 3000 requests Completed 3500 requests Completed 4000 requests Completed 4500 requests Completed 5000 requests Finished 5000 requests Server Software: nginx/1.10.1 Server Hostname: localhost Server Port: 80 Document Path: / Document Length: 3698 bytes Concurrency Level: 500 Time taken for tests: 0.758 seconds Complete requests: 5000 Failed requests: 0 Write errors: 0 Total transferred: 19660000 bytes HTML transferred: 18490000 bytes Requests per second: 6593.48 [#/sec] (mean) Time per request: 75.832 [ms] (mean) Time per request: 0.152 [ms] (mean, across all concurrent requests) Transfer rate: 25317.93 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 6 11.0 2 53 Processing: 5 19 8.2 17 53 Waiting: 0 18 8.2 16 47 Total: 10 25 17.4 18 79 Percentage of the requests served within a certain time (ms) 50% 18 66% 21 75% 21 80% 22 90% 69 95% 73 98% 75 99% 76 00% 79 (longest request) [[email protected] ~]#
WOW!
As-tu vu ça?
Nginx a traité 6593 requêtes par seconde ! Un gagnant.
Donc, vous voyez juste en comparant avec deux serveurs Web, vous aurez une idée de celui à choisir pour votre application Web.
Le test ci-dessus est sur CentOS 6.8, 64 bits. Vous pouvez essayer plusieurs combinaisons de versions de système d’exploitation et de serveur Web pour des résultats optimaux.
Vous n’aimez pas ApacheBench pour une raison quelconque ? Pas de soucis, il y en a beaucoup d’autres que vous pouvez utiliser pour effectuer un chargement HTTP.
SIÈGE
SIÈGE est un utilitaire de test de charge HTTP pris en charge sous UNIX. Vous pouvez mettre plusieurs URL dans un fichier texte pour charger des tests. Vous pouvez installer le siège en utilisant yum.
# yum install siege
Exécutons le test avec 500 requêtes simultanées pendant 5 secondes.
[[email protected] ~]# siege -q -t 5S -c 500 http://localhost/ Lifting the server siege... done. Transactions: 4323 hits Availability: 100.00 % Elapsed time: 4.60 secs Data transferred: 15.25 MB Response time: 0.04 secs Transaction rate: 939.78 trans/sec Throughput: 3.31 MB/sec Concurrency: 37.97 Successful transactions: 4323 Failed transactions: 0 Longest transaction: 1.04 Shortest transaction: 0.00 [[email protected] ~]#
Décomposer les paramètres.
-q – pour l’exécuter silencieusement (sans afficher les détails de la demande)
-t – exécuter pendant 5 secondes
-c – 500 requêtes simultanées
Ainsi, comme vous pouvez le constater, la disponibilité est de 100 % et le temps de réponse est de 0,04 seconde. Vous pouvez modifier le paramètre de test de charge en fonction de votre objectif.
Ali
Ali est un outil de test de charge relativement nouveau pour effectuer une analyse en temps réel. Il prend en charge plusieurs plates-formes à installer, y compris Docker.
Une fois installé, exécutez ali pour voir les détails d’utilisation.
[email protected]:~# ali
no target given
Usage:
ali [flags] <target URL>
Flags:
-b, --body string A request body to be sent.
-B, --body-file string The path to file whose content will be set as the http request body.
--debug Run in debug mode.
-d, --duration duration The amount of time to issue requests to the targets. Give 0s for an infinite attack. (default 10s)
-H, --header strings A request header to be sent. Can be used multiple times to send multiple headers.
-k, --keepalive Use persistent connections. (default true)
-M, --max-body int Max bytes to capture from response bodies. Give -1 for no limit. (default -1)
-m, --method string An HTTP request method for each request. (default "GET")
-r, --rate int The request rate per second to issue against the targets. Give 0 then it will send requests as fast as possible. (default 50)
-t, --timeout duration The timeout for each request. 0s means to disable timeouts. (default 30s)
-v, --version Print the current version.
Examples:
ali --duration=10m --rate=100 http://host.xz
Author:
Ryo Nakao <[email protected]>
[email protected]:~#Comme vous pouvez le voir ci-dessus, vous avez la possibilité d’envoyer des en-têtes HTTP, la durée du test, la limite de débit, le délai d’expiration, etc. J’ai fait un test rapide sur toptips.fr Tools et voici la sortie ressemble.
Le rapport est interactif et donne des informations détaillées sur la latence.
Gobench
Gobench est écrit en langage Go et un utilitaire de test de charge simple pour évaluer les performances du serveur Web. Il prend en charge plus de 20 000 utilisateurs simultanés, contrairement à ApacheBench.
Apache JMeter
Jmètre est l’un des outils open source les plus populaires pour mesurer les performances des applications Web. JMeter est une application basée sur Java et pas seulement un serveur Web, mais vous pouvez l’utiliser contre PHP, Java. ASP.net, SOAP, REST, etc.
JMeter a une interface graphique conviviale et décente, et la dernière version 3.0 nécessite Java 7 ou supérieur pour lancer l’application. Vous devez essayer JMeter si votre objectif est d’optimiser les performances de l’application Web.
travail
travail est un autre outil moderne de mesure des performances pour mettre une charge sur votre serveur Web et vous donner des détails sur la latence, la demande par seconde, le transfert par seconde, etc.
Avec wrk, vous pouvez spécifier d’exécuter un test de charge avec un certain nombre de threads.
Prenons un exemple d’exécution d’un test pendant 5 minutes avec 500 utilisateurs simultanés avec 8 threads.
wrk –t8 –c500 -d300s http://localhost
Canon automatique
Inspiré par le travail, canon automatique est écrit en Node.js. Vous pouvez l’utiliser par programmation, via une API ou un utilitaire autonome. Tout ce dont vous avez besoin est NodeJS installé comme prérequis.
Vous pouvez contrôler un certain nombre de connexions, de requêtes, de durées, de travailleurs, de délais d’attente, de taux de connexion et offrir des tonnes d’options pour comparer vos applications Web.
Curl-loader
chargeur de boucles est écrit en C pour simuler la charge de l’application et prend en charge SSL/TLS. Parallèlement au test de la page Web, vous pouvez également utiliser cet outil open source pour effectuer une charge sur les serveurs FTP.
Vous pouvez créer un plan de test avec un mélange de HTTP, HTTPS, FTP et FTPS dans une seule configuration de lot.
httperf
La httperf est un outil performant qui se concentre sur les benchmarks au niveau micro et macro. Il prend en charge les protocoles HTTP/1.1 et SSL.
Si vous avez le nombre attendu d’utilisateurs simultanés et que vous cherchez à tester si votre serveur Web peut répondre à un certain nombre de requêtes, vous pouvez utiliser la commande suivante.
httperf --server localhost --port 80 --num-conns 1000 --rate 100
La commande ci-dessus testera avec 100 requêtes par seconde pour 1000 requêtes HTTP.
Tsung
Tsung est un outil de test de stress distribué multi-protocoles pour stresser les serveurs HTTP, SOAP, PostgreSQL, LDAP, XAMP, MySQL. Il prend en charge HTTP/1.0, HTTP/1.1 et les cookies sont automatiquement gérés.
Générer un rapport est faisable avec Tsung.
Conclusion
J’espère que les outils d’analyse comparative ci-dessus vous donneront une idée des performances de votre serveur Web et décideront ce qui convient le mieux à votre projet.
Ensuite, n’oubliez pas de surveiller les performances de votre site Web.