Tu parles de JMeter? Très probablement, si vous êtes dans le sujet, vous avez déjà tout lu sur cet outil pour les tests de stress. Mais j'ai quelque chose pour vous surprendre. Pendant trois ans chez QA, j'ai réalisé que JMeter est très polyvalent et peut être utilisé à diverses fins. Par exemple, pour:
- rechercher un bug insaisissable avec la chute du site pour certains utilisateurs;
- réchauffement rapide du cache sur des milliers de pages produits;
- tester le backend d'une application mobile;
- création de 2000 enregistrements avec des données utilisateur dans la base de données d'application en peu de temps.
Si vous êtes intéressé, bienvenue au chat. Il s'est avéré volumineux, donc je vais diviser l'article en deux parties.
Avertissement: Pour des raisons évidentes, je n'insère pas de captures d'écran de projets réels dans l'article (ni n'en extrait toutes les informations importantes). Les illustrations sont fournies à des fins de recherche et d'enseignement uniquement.
Application JMeter classique
JMeter - applet Java avec interface graphique. Pour les tests, il démarre sans interface graphique. Et pour écrire des scripts de test, il a un panneau dans lequel vous pouvez faire n'importe quoi.
Voici à quoi ressemble le processus de création du script (ici même le mot "écriture" ne convient pas)Un plan de test commun est créé, dans lequel le groupe de threads se jette avec les principaux éléments du test: les contrôleurs de processus et les requêtes (HTTP, FTP, etc.).
De plus, il existe des éléments supplémentaires pour définir les paramètres. Par exemple, HTTP Request Defaults vous permet de spécifier le serveur principal, les en-têtes et d'activer / désactiver le téléchargement d'actifs supplémentaires (images, styles, polices, etc.). C'est facile à comprendre. Et vous pouvez immédiatement exécuter un test à partir de cette interface et consulter les résultats.
JMeter peut enregistrer de tels cas de test. Il s'exécute en tant que proxy sur la machine locale et, si vous configurez un navigateur (ou une application), générez du trafic via ce proxy, JMeter enregistrera toutes les demandes et réponses. Et à partir de cet ensemble, vous pouvez concocter un script de test qui va répéter les actions de l'utilisateur, et l'exécuter où et quand vous le souhaitez:
Le problème principal est le tas de mémoire de Java lui-même. Il repose sur le plafond et peut tomber avec 50 fils de tests simultanés, même sur des machines haut de gamme.
Si la machine n'a pas assez de puissance pour un test à pleine charge, contactez une organisation tierce. Ils ont déployé une infrastructure qui est un ensemble de serveurs. Ils ont obtenu le même JMeter. Moyennant des frais, ces gars exécuteront votre script sur n'importe quelle charge. Nous avons demandé ces services chez Octoperf et Blazemeter.
C'est le football, bébé: comment nous avons attrapé un bug avec un crash partiel du serveur
Nous sommes engagés dans le développement Web depuis 18 ans (cheers - maintenant vous pouvez fumer, vous marier et regarder John Wick). Il y a eu de nombreux clients au cours de leur vie, mais les plus importants sont apparus récemment. Par exemple, nous avons créé un site sur
Sitecore pour l'un des clubs de football de la Premier League anglaise avec le paradigme SPW (site Web à page unique: toutes les pages s'ouvrent sans recharger la page du navigateur elle-même). Sous le capot se trouve le panneau d'administration pour gérer une page de match en direct. Il s'agit d'une diffusion textuelle en ligne du jeu: les principaux événements (buts, suppressions, coups francs) sont chargés automatiquement à partir du système Opta, et les photos, commentaires et reposts des fans de Twitter et Instagram sont publiés par des personnes en direct - gestionnaires de contenu de club de football.
Je note avec fierté: après la sortie, les médias britanniques ont publié des articles sous les titres «Enfin, l’hégémonie des anciens sites des clubs de football est terminée. A cette époque, la plupart des clubs avaient déjà des sites. Mais ils semblaient avoir été développés au début des années 2000 et n'ont pas changé depuis - avec le design et l'UX correspondants.
Avant le lancement, nous avons effectué un test de pleine charge et nous nous sommes assurés que tout fonctionne comme il se doit. La structure du serveur ressemblait à ceci:
- la demande du client va au serveur d'équilibrage de charge →
- le serveur d'équilibrage de charge vérifie l'état de huit serveurs CD →
- le serveur d'équilibrage de charge envoie une demande au serveur de CD le moins chargé →
- Le serveur de CD répond au client.
Un an après le lancement, lors d'un afflux important d'utilisateurs sur le site, le client a appelé et déclaré que le site était en panne:
- Notre site ne fonctionne pas! Ça ne marche pas du tout! Juste un écran blanc et une inscription du navigateur que le site est en panne! - dit le client.
Nous sommes dans une panique ouvrant le site, et avec lui tout va bien:
«Cela fonctionne toujours», répondons-nous.
Le client ouvre le site depuis le téléphone et l'ordinateur et ... tout va bien aussi!
- Vraiment, désolé. Apparemment, les utilisateurs ont des problèmes.
Ces messages n'apparaissent pas à partir de zéro, nous avons donc mené une étude: nous avons lancé un utilitaire de surveillance de l'état des serveurs Server Density et regardé ce qui leur arrivait lors d'un afflux d'utilisateurs sur le site:
Il y a une charge, mais tous les serveurs de CD se ressemblent et mêmeBientôt, l'histoire s'est répétée - certains utilisateurs ont signalé un site complètement cassé. Ce n'était pas une erreur ou une page introuvable - le serveur n'a tout simplement pas répondu à la demande. Il a été possible de rattraper la situation avec l'aide de JMeter.
L'objectif était simple: charger les huit serveurs et voir ce qui se passe. Un test de résistance a été effectué à l'aube à Tcheliabinsk, et à Londres, la nuit a été profonde. Nous avons utilisé plusieurs machines en mode non-interface (cela vous permet d'exécuter beaucoup plus de threads en même temps). Le script a sans cesse ouvert la page d'accueil, et c'était notre principale erreur.
Nous avons téléchargé les mêmes actifs qui étaient déjà mis en cache cent fois. Par conséquent, la charge est sortie insignifiante. Puis l'idée est venue: sur le site - un chariot et un petit panier de pages avec des nouvelles pour certaines dates. Si vous avancez quelques variables et les substituez dans l'URL, nous aurons toujours une page aléatoire (par exemple - ... url / news / 2016/08/23 /? Page = 4).
Du coup, nous avons réalisé que Server Density avait un certain «lissage» intégré dans les graphiques de la charge du serveur au cours des périodes passées. Si, en cinq minutes, la charge sur le serveur atteint 100%, puis tombe à 0%, et après 20-30 secondes a augmenté à 90%, il affichera la valeur moyenne pour cette période - environ 80-90%. Par conséquent, nous n'avons pas vu de véritable panne de serveur.
Après avoir examiné les journaux en détail lors des tests de résistance, nous avons découvert que l'un des serveurs de CD s'est redémarré à 100% et n'en a parlé à personne (il est tellement introverti).
L'équilibreur de charge n'a examiné que l'utilisation du processeur de tous les serveurs. Il a vu que l'un d'entre eux était chargé à 20% et le reste à 90% et a envoyé l'utilisateur au premier. Et il était en train de redémarrer et a donné un écran blanc. De plus, le serveur de distribution a exposé l'utilisateur à un cookie et l'a lié étroitement au serveur inactif. Par conséquent, même après la mise à jour, le site n'était pas disponible. Les 7 autres utilisateurs sur 8 en même temps ont apprécié la vie et ont dit que tout fonctionnait.
Conclusion:
nous avons constaté que JMeter peut être utilisé pour les tests de résistance et en même temps analyser l'état des serveurs lors des tests avec d'autres outils. Nous avons réussi à «attraper» le problème de la chute du site chez certains utilisateurs et à le résoudre en corrigeant la logique de répartition de la charge et en ajoutant un contrôle d'état.
Dans la partie suivante, je vais vous expliquer comment, avec l'aide de JMeter, nous avons mis en place le processus de mise en cache des pages produits, testé le fonctionnement d'une application mobile sans l'application elle-même et créé 2000 utilisateurs dans le système sans accès à la base de données.