Articles

Test de charge de votre application avec Siege

Juillet 2019

balise(s): rails_performance • rails • programmation
Temps de lecture: 8 minutes
  • Dumping d’URL uniques dans un fichier texte
  • Visite de toutes ces pages dans un Test de siège
  • Ressources supplémentaires

La dernière fois, j’ai utilisé Apache Benchmark pour effectuer des tests de performances sur une page nécessitant une authentification pour y accéder.

Aujourd’hui, nous allons comprendre comment utiliser siege pour visiter de nombreuses URL uniques sur notre page et obtenir des benchmarks sur ce processus. Je vais ensuite comprendre le profilage des performances dans Datadog, et avec ces trois outils réunis, nous devrions être prêts à apporter des améliorations significatives à notre application.

Cette série de messages est le résultat direct du Guide complet des performances des rails de Nate Berkopec, avec l’aide de ses screencasts, ainsi que des applications de test de charge des Rails de Steve Grossi avec Apache Bench, Siege et JMeter. Armés de ces ressources, et debout sur des épaules de géants, c’est parti.

Description du siège:

Siege est un utilitaire de test de charge http et d’analyse comparative. Il a été conçu pour permettre aux développeurs web de mesurer leur code sous la contrainte, pour voir comment il résistera au chargement sur Internet. Siege prend en charge l’authentification de base, les cookies, les protocoles HTTP, HTTPS et FTP. Il permet à son utilisateur de frapper un serveur avec un nombre configurable de clients simulés. Ces clients placent le serveur  » en état de siège. »

Vous pouvez obtenir le siège avec brew install siege.

Je l’utilise car il peut exécuter une liste d’URL que vous lui donnez. Imaginez que votre application est un magasin et qu’elle répertorie quelques milliers de produits. Chaque produit doit avoir une URL unique, quelque chose comme , ou peut-être . Cela product-guid garantit que vous pouvez avoir des URL uniques, même s’il y a deux éléments avec le même nom de produit.

Sachant ce qu’il y a dans votre base de données, vous pouvez facilement concater product-guid et product-name, le coller à la fin de et créer une liste de cent, mille ou dix mille URL de produit uniques dans votre application. Si vous les enregistrez dans un fichier texte et que Siege visite chacune de ces pages le plus rapidement possible this cela pourrait ressembler à une sorte de bon test de résistance, hein?

Vider des URL uniques dans un fichier texte #

Vous commencerez probablement à travailler dans une session rails console, pour comprendre comment accéder au schéma d’URL juste.

J’ai déclenché la console et entré:

J’ai regardé dans notre base de données de développement pour trouver un compte avec beaucoup de données; le compte avec l’id 4887 est un compte associé à l’automatisation de l’assurance qualité et contient beaucoup de données.

campaign.to_param est la façon dont nous construisons des URL à partir de nos campagnes – il concatrie simplement la guid avec la chaîne title, telle que fournie par le client, et appelle .parameterize dessus. Pour ce lot de campagnes, elles sont générées par programme par notre suite de tests d’assurance qualité automatisée.

Une fois terminé, vous pourriez voir quelque chose comme ceci dans all_campaign_urls.txt:

En visitant toutes ces pages dans un test de siège #

, vous pouvez donc siege --help et voir un drapeau pour passer dans un fichier:

Je sais déjà que nous aurons besoin de --file, et --header, car nous devrons simuler des sessions authentifiées en soumettant des cookies, le processus pour lequel j’ai décrit la dernière fois

Le drapeau --get semble utile:

OBTENEZ, tirez vers le bas les en-têtes HTTP et affichez la transaction. Idéal pour le débogage d’applications.

Alors, connectez-vous en tant que compte QA. Puisque j’exécute tout cela localement, je peux trouver l’adresse e-mail associée dans notre base de données. Je ne connais pas le mot de passe, bien sûr, mais je peux forcer une réinitialisation du mot de passe local, récupérer l’e-mail dans Mailcatcher et le définir sur le mot de passe que je veux.

Permet d’entrer ces en-têtes.

Nous pouvons faire une demande de test de boucles avec nos cookies. Quand je le fais

$ curl -v http://localhost:3000/account/campaigns/dd4dfb48aa-dec-05-drive-by-test

Je m’attends à voir la page revenir, pas une redirection vers /users/sign_in

À quoi je m’attends à ce qu’une authentification échouée ressemble :

cookies:

_ts_session_id: c86fd1fe38d7a6c56ce1ef5990045057fd827a2c5655094bcce3748d6ee6d3e4: ImRhMDY1YjdjYjMwNGNjNWUxNzFkNDhjOGQ0YzA0OTIwIg%3D%3D--98c228cb35af1a269ee894c22540b81848e2ed09

Et nous sommes en affaires:

Remarquez ces codes d’état de 200? Je peux tail -f log/development.log et voir toute l’activité, indiquant que les cookies soumis sont associés à un utilisateur authentifié.

La première chose que je remarque est qu’il semble que ce soient des temps de chargement de pages extrêmement longs.

J’ai une charge de siège d’environ 162 URL différentes. Lorsque vous exécutez siege avec la configuration par défaut, il exécute 20 utilisateurs simultanés. Cela semblait être un peu trop pour ce que mon localhost pouvait gérer, j’ai donc essayé de réduire le nombre d’utilisateurs simultanés d’abord à deux utilisateurs, puis à un.

Pour définir le nombre d’utilisateurs simultanés, ajoutez simplement l’indicateur --concurrent=NUM. J’étais toujours inondé de sortie, j’ai donc supprimé les utilisateurs simultanés à 1 et supprimé toutes les pages sauf 20 de la liste des pages à charger. Je lui ai donné un drapeau time de 60 secondes, ainsi que: -t 60s

Lorsque tout est dit et fait, vous verrez siege faire un tas de requêtes GET chronométrées, comme ceci:

Finalement, tout se réglera et vous obtiendrez un résumé du test de charge:

Ouais, OK, c’est cool, Josh, mais en quoi est-ce que je suis censé faire quelque chose d’utile avec ça?

Excellente question! Il est temps de voir où notre application passe la plupart de son temps, dans le monde réel. Nous pourrions faire plus de benchmarking localement, mais il est évident que les données du monde réel, recueillies auprès de personnes réelles interagissant avec votre application réelle en production, sont la source de données la plus utile.

Par conséquent, je vais bientôt écrire que j’ai écrit sur la façon d’obtenir des données utiles d’une application Rails dans DataDog!

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.