Comment utiliser Apache JMeter pour effectuer des tests de charge sur un serveur Web

introduction

Dans ce didacticiel, nous verrons comment utiliser Apache JMeter pour effectuer des tests de charge et de contrainte de base sur votre environnement d’application Web. Nous allons vous montrer comment utiliser l’interface utilisateur graphique pour créer un plan de test et exécuter des tests sur un serveur Web.

JMeter est une application Java de bureau open source conçue pour charger des tests et mesurer les performances. Il peut être utilisé pour simuler des charges de divers scénarios et des données de performance de sortie de plusieurs manières, notamment des fichiers CSV et XML, ainsi que des graphiques. Parce qu’il est 100% Java, il est disponible sur tous les systèmes d’exploitation prenant en charge Java 6 ou version ultérieure.

Conditions préalables

Pour suivre ce didacticiel, vous devez disposer d’un ordinateur sur lequel vous pouvez exécuter JMeter et d’un serveur Web avec lequel charger le test. N’exécutez pas ces tests sur vos serveurs de production, sauf si vous savez qu’ils peuvent gérer la charge, sinon vous pourriez nuire aux performances de votre serveur.

Vous pouvez adapter les tests de ce didacticiel à n’importe laquelle de vos propres applications Web. Le serveur Web que nous testons à titre d’exemple est un VPS de 1 CPU / 512 Mo exécutant WordPress sur une pile LEMP, dans le centre de données NYC2 DigitalOcean. L’ordinateur JMeter fonctionne dans le bureau de DigitalOcean à New York (ce qui est lié à la latence de nos tests).

Veuillez noter que les résultats du test JMeter peuvent être faussés par divers facteurs, notamment les ressources système (CPU et RAM) disponibles pour JMeter et le réseau entre JMeter et le serveur Web testé. La taille de la charge que JMeter peut générer sans fausser les résultats peut être augmentée en exécutant les tests en mode non graphique ou en répartissant la génération de charge sur plusieurs serveurs JMeter.

Installer JMeter

Étant donné que nous utilisons Apache JMeter en tant qu’application de bureau et que de nombreux systèmes d’exploitation de bureau sont utilisés, nous ne couvrirons pas les étapes d’installation de JMeter pour un système d’exploitation spécifique. Cela dit, JMeter est très facile à installer. Le moyen le plus simple d’installer consiste à utiliser un gestionnaire de paquets (par exemple, apt-get ou Homebrew), ou téléchargez et désarchivez les fichiers binaires JMeter sur le site officiel et installez Java (version 6 ou ultérieure).

Voici une liste du logiciel, avec des liens vers des archives, * requis * pour exécuter JMeter:

En fonction de la manière dont vous installez Java, vous devrez peut-être ajouter le répertoire bin Java à votre variable d’environnement + PATH + afin que JMeter puisse trouver les fichiers binaires Java et Keytool.

De plus, nous ferons référence au chemin sur lequel vous avez installé JMeter (le répertoire dans lequel vous l’avez désarchivé) par + $ JMETER_HOME +. Par conséquent, si vous utilisez un système d’exploitation Linux ou Unix, le binaire JMeter se trouve à + ​​$ JMETER_HOME / bin / jmeter +. Si vous utilisez Windows, vous pouvez exécuter + $ JMETER_HOME / bin / jmeter.bat +.

Pour référence, lors de la rédaction de ce tutoriel, nous avons utilisé les versions de logiciel suivantes:

  • Oracle Java 7 mise à jour 60, 64 bits

  • JMeter 2.11

Une fois JMeter installé et opérationnel, commençons par élaborer un plan de test!

Construire un plan de test de base

Après avoir démarré JMeter, l’interface utilisateur graphique devrait apparaître avec un Test Plan vide:

image: https: //assets.digitalocean.com/articles/jmeter/jmeter_start.png [Interface graphique JMeter]

Un plan de test est composé d’une séquence de composants de test qui déterminent comment le test de charge sera simulé. Nous expliquerons comment certains de ces composants peuvent être utilisés au fur et à mesure que nous les ajoutons à notre plan de test.

Ajouter un groupe de discussion

Tout d’abord, ajoutez un groupe de threads au plan de test:

  1. Faites un clic droit sur Test Plan

  2. Passez la souris sur _Ajouter> _

  3. Passez la souris sur _Threads (utilisateurs)> _

  4. Cliquez sur Thread Group

Le Thread Group a trois propriétés particulièrement importantes qui influencent le test de charge:

  • * Nombre de threads (utilisateurs) *: Nombre d’utilisateurs que JMeter tentera de simuler. Définissez ceci sur * 50 *

  • * Période d’accélération (en secondes) *: La durée pendant laquelle JMeter distribuera le début des threads. Définissez ceci sur * 10 *.

  • * Nombre de boucles *: Le nombre de fois où exécuter le test. Laissez ce paramètre sur * 1 *.

image: https: //assets.digitalocean.com/articles/jmeter/thread_group1.png [Propriétés du groupe de threads]

Ajouter une requête HTTP par défaut

L’élément HTTP Request Defaults Config est utilisé pour définir les valeurs par défaut des requêtes HTTP dans notre plan de test. Ceci est particulièrement utile si nous voulons envoyer plusieurs demandes HTTP au même serveur dans le cadre de notre test. Ajoutons maintenant les requêtes HTTP par défaut à _Thread Group:

  1. Sélectionnez Thread Group, puis cliquez dessus avec le bouton droit de la souris.

  2. Passez la souris sur _Ajouter> _

  3. Passez la souris sur _Config Element> _

  4. Cliquez sur HTTP Request Defaults

Dans Requêtes HTTP par défaut, dans la section Serveur Web, renseignez le champ Nom du serveur ou IP_ avec le nom ou l’adresse IP du serveur Web que vous souhaitez tester. Définir le serveur ici en fait le serveur par défaut pour le reste des éléments de ce groupe de threads.

image: https: //assets.digitalocean.com/articles/jmeter/http_request_defaults.png [Paramètres par défaut de la requête HTTP]

Ajouter un gestionnaire de cookies HTTP

Si votre serveur Web utilise des cookies, vous pouvez ajouter un support pour les cookies en ajoutant un gestionnaire de cookies HTTP au groupe de discussion:

  1. Sélectionnez Thread Group, puis cliquez dessus avec le bouton droit de la souris.

  2. Passez la souris sur _Ajouter> _

  3. Passez la souris sur _Config Element> _

  4. Cliquez sur HTTP Cookie Manager

Ajouter un échantillonneur de requêtes HTTP

Maintenant, vous voudrez ajouter un échantillonneur de requêtes HTTP à _Thread Group, qui représente une requête de page à laquelle chaque thread (utilisateur) aura accès:

  1. Sélectionnez Thread Group, puis cliquez dessus avec le bouton droit de la souris.

  2. Passez la souris sur _Ajouter> _

  3. Passez la souris sur _Sampler> _

  4. Cliquez sur HTTP Request

Dans Requête HTTP, sous la section Requête HTTP, renseignez Path avec l’élément que vous souhaitez que chaque thread (utilisateur) demande. Nous allons régler cela sur + / +, ainsi chaque fil va accéder à la page d’accueil de notre serveur. Notez qu’il n’est pas nécessaire de spécifier le serveur dans cet élément, car il a déjà été spécifié dans l’élément HTTP Request Defaults.

  • Remarque: * Si vous souhaitez ajouter plus de demandes HTTP dans le cadre de votre test, répétez cette étape. Chaque thread effectuera toutes les demandes de ce plan de test.

Ajouter un affichage des résultats dans un écouteur de table

Dans JMeter, les écouteurs sont utilisés pour générer les résultats d’un test de charge. Il existe une variété d’écouteurs disponibles, et les autres écouteurs peuvent être ajoutés en installant des plugins. Nous allons utiliser le tableau car il est facile à lire.

  1. Sélectionnez Thread Group, puis cliquez dessus avec le bouton droit de la souris.

  2. Passez la souris sur _Ajouter> _

  3. Passez la souris sur _Listener> _

  4. Cliquez sur Afficher les résultats dans le tableau.

Vous pouvez également saisir une valeur pour Filename afin de générer les résultats dans un fichier CSV.

Exécuter le plan de test de base

Maintenant que notre plan de test de base est configuré, exécutons-le et voyons les résultats.

Commencez par enregistrer le plan de test en cliquant sur Fichier puis sur Enregistrer, puis indiquez le nom du fichier souhaité. Sélectionnez ensuite Affichage des résultats dans Tableau dans le volet de gauche, puis cliquez sur Run dans le menu principal, puis sur Start (ou cliquez simplement sur la flèche verte en dessous du menu principal). Vous devriez voir les résultats du test dans la table car le test est exécuté comme suit:

image: https: //assets.digitalocean.com/articles/jmeter/results_table1.png [Tableau des résultats du test]

Interpréter les résultats

Vous verrez probablement que le statut de toutes les demandes est «Réussite» (indiqué par un triangle vert avec une coche). Après cela, les colonnes qui vous intéressent probablement le plus sont les colonnes Sample Time (ms) _ et _ Latency _ (non affichées dans l’exemple).

  • * Latence *: le nombre de millisecondes qui s’est écoulé entre le moment où JMeter a envoyé la demande et le moment où une réponse initiale a été reçue.

  • * Sample Time *: le nombre de millisecondes nécessaires au serveur pour répondre pleinement à la demande (réponse + latence)

Selon le tableau généré, la plage de temps d’échantillonnage est comprise entre 128 et 164 ms. C’est un temps de réponse raisonnable pour une page d’accueil de base (environ 55 Ko). Si votre serveur d’applications Web ne lutte pas pour les ressources, comme illustré dans l’exemple, votre temps d’échantillonnage sera principalement influencé par la distance géographique (ce qui augmente généralement le temps de latence) et la taille de l’élément demandé (ce qui augmente le temps de transfert). Vos résultats personnels varieront de l’exemple.

Notre serveur a donc survécu à notre simulation de 50 utilisateurs accédant à notre page d’accueil WordPress de 55 Ko sur 10 secondes (5 toutes les secondes), avec une réponse acceptable. Voyons ce qui se passe lorsque nous augmentons le nombre de threads.

Augmenter la charge

Essayons le même test avec 80 threads sur 10 secondes. Dans l’élément Thread Group du volet de gauche, définissez le nombre de threads (utilisateurs) _ sur * 80 *. Maintenant, cliquez sur Afficher les résultats dans le tableau, puis cliquez sur _Start. Sur notre exemple de serveur, cela donne le tableau suivant:

image: https: //assets.digitalocean.com/articles/jmeter/results_table2.png [Tableau des résultats 2]

Comme vous pouvez le constater, le temps d’échantillonnage a augmenté d’environ une seconde, ce qui indique que notre serveur d’applications Web commence à être surchargé par les demandes. Connectez-vous à notre VPS et voyez un rapide aperçu de l’utilisation des ressources pendant le test de charge.

Connectez-vous à votre serveur Web via SSH et exécutez + top +:

top

Sauf si des utilisateurs frappent activement votre serveur, vous devriez voir que le nombre d’utilisations utilisateur (us) du ou des processeurs doit être très faible ou égal à 0%, et que le% d’inactivité (id) du ou des processeurs doit être égal à 99% +, comme alors:

image: https: //assets.digitalocean.com/articles/jmeter/top_idle.png [Sortie en haut à vide]

Maintenant, dans * JMeter *, relancez le test, puis revenez à la session SSH de votre serveur Web. Vous devriez voir l’utilisation des ressources augmenter:

image: https: //assets.digitalocean.com/articles/jmeter/top_max_cpu.png [Sortie maximale de la CPU]

Dans le cas de notre exemple, le pourcentage d’utilisation de l’unité centrale est de 94% et celui du système (sy) de 4,7% avec 0% d’inactivité. Comme nous le voyons dans l’image ci-dessus, nous ne manquons pas de mémoire. La baisse des performances est donc due au manque de puissance du processeur! Nous pouvons également voir que les processus php5-fpm, qui servent WordPress, utilisent la majorité du processeur (environ 96% combinés).

Afin de répondre aux exigences de cette simulation de 80 utilisateurs en 10 secondes, nous devons soit augmenter notre processeur, soit optimiser la configuration de notre serveur pour utiliser moins de processeur. Dans le cas de WordPress, nous pourrions déplacer la base de données MySQL (qui utilise une partie du processeur) vers un autre serveur et implémenter la mise en cache (ce qui réduirait l’utilisation du processeur).

Si vous êtes curieux, vous pouvez ajuster le nombre de threads dans le test pour voir combien de serveurs votre serveur peut gérer avant qu’il ne commence à présenter une dégradation des performances. Dans le cas de notre exemple de gouttelette 1 CPU, cela fonctionne bien jusqu’à ce que nous utilisions 72 threads sur 10 secondes.

Conclusion

JMeter peut être un outil très précieux pour déterminer comment améliorer la configuration de votre serveur d’applications Web, pour réduire les goulots d’étranglement et augmenter les performances. Maintenant que vous êtes familiarisé avec l’utilisation de base de JMeter, n’hésitez pas à créer de nouveaux plans de test pour mesurer les performances de vos serveurs dans différents scénarios.

Le test que nous avons utilisé dans cet exemple ne reflète pas avec précision le modèle d’utilisation d’un utilisateur normal, mais JMeter dispose des outils nécessaires pour effectuer divers tests pouvant être utiles dans votre propre environnement. Par exemple, JMeter peut être configuré pour simuler la connexion d’un utilisateur à votre application, la mise en cache côté client et la gestion de sessions utilisateur avec la réécriture d’URL. Il existe de nombreux autres échantillonneurs, écouteurs et outils de configuration intégrés qui peuvent vous aider à créer votre scénario souhaité. De plus, des plugins JMeter améliorant ses fonctionnalités sont disponibles au téléchargement sur http://jmeter-plugins.org/.