Effectuer un test de Stress sur une Application Web?

voici un autre vote pour JMeter .

JMeter est un outil open-source de test de charge, écrit en Java. Il est capable de tester un certain nombre de types de serveurs différents (par exemple, web, services web, base de données, à peu près tout ce qui utilise des requêtes essentiellement).

il a cependant une courbe d'apprentissage raide une fois que vous commencez à obtenir des tests compliqués, mais il est bien la peine. Vous pouvez vous lever et courir très vite, et selon le type de stress-test que vous voulez faire, cela pourrait être bien.

Pour:

• Open Source/Libre de l'outil du projet Apache (aide avec des buy-in)
• facile à démarrer, et facile à utiliser une fois que vous saisissez les concepts de base. (C'est à dire, comment faire pour créer une demande, comment créer une assertion, comment travailler avec des variables, etc).
• très évolutif. J'ai l'exécution des tests avec 11 machines générant une charge sur le serveur de près d'un million de hits/heure. Il était beaucoup plus facile à configurer que je m'y attendais.
• a une communauté active et de bonnes ressources pour vous aider à démarrer. Lisez d'abord les tutoriels et jouez avec pendant un certain temps.

Inconvénients:

• L'interface utilisateur est écrite en Swing. (pouah!)
• JMeter des œuvres de analyse du texte de réponse retourné par le serveur. Donc, si vous cherchez à valider toute sorte de comportements javascript, vous n'avez pas de chance.
• courbe d'Apprentissage est raide pour les non-programmeurs. Si vous êtes familier avec les expressions régulières, vous êtes déjà en avance sur le jeu.
• il y a un grand nombre de ( insert expretive ) idiots dans le forum de soutien posant des questions stupides qui pourraient être facilement résolus si elles donneraient le documentation même un coup d'oeil rapide. ("Comment utiliser JMeter pour tester mon interface graphique Windows" apparaît assez fréquemment).
• Reporting "de la case" laisse beaucoup à désirer, notamment pour les plus grandes épreuves. Dans le test que j'ai mentionné ci-dessus, j'ai fini par avoir à écrire une application de console rapide pour faire certaines des conversions 'xml-logfile' en 'html'. C'était il y a quelques années, donc il est probable que ce ne serait plus requise.

j'ai utilisé La meule . Il est open source, assez facile à utiliser, et très configurable. Il est basé sur Java et utilise le Jython pour les scripts. Nous l'avons comparé à une application web.net, donc ne pensez pas que C'est un outil Java seulement (par leur nature, tout outil de stress web ne devrait pas être lié à la plate-forme qu'il utilise).

on a fait des trucs sympas avec... nous étions une application de télécommunications basée sur le web, donc une utilisation cool que j'ai mis en place était d'imiter la composition d'un nombre grâce à notre application web, nous avons ensuite utilisé un outil de réponse automatique que nous avions (qui était essentiellement une application tutorielle de Microsoft pour se connecter à leur serveur RTC LCS... ce à quoi Microsoft Office Communicator se connecte sur un réseau local... ensuite modifiée pour prendre les appels automatiquement). Cela nous a permis d'utiliser ceci à la place d'un outil de téléphonie coûteux appelé le marteau (ou quelque chose comme ça).

de toute façon, nous avons également utilisé l'outil pour voir comment notre application détenus jusqu' sous forte charge, et il a été très efficace pour trouver les goulots d'étranglement. L'outil a été intégré dans les rapports pour montrer combien de temps prennent les demandes, mais nous ne l'avons jamais utilisé. Les journaux peuvent également stocker toutes les réponses et autres joyeusetés, ou de journalisation personnalisé.

je recommande fortement cet outil, très utile pour le prix... mais attendez-vous à faire une configuration personnalisée avec (il a un proxy intégré pour enregistrer un script, mais il peut avoir besoin de personnalisation pour capturer quelque chose comme des sessions... Je sais que j'ai eu à personnalisez - le pour utiliser une session unique par thread).

Un peu tard pour cette partie. Je suis d'accord que Pylot est le meilleur outil open source à venir là-bas. Il est simple à utiliser et est activement travaillé par un grand gars ( Corey Goldberg ). En tant que fondateur de OpenQA , Je suis également heureux que Pylot est maintenant répertorié sur notre page d'accueil et utilise une partie de notre infrastructure (à savoir les forums).

cependant, j'ai également récemment décidé que l'ensemble du concept de les tests de charge étaient imparfaits: émuler le trafic HTTP, avec des applications aussi complexes qu'elles le sont devenues, est une plaie. C'est pourquoi j'ai créé L'outil commercial BrowserMob. C'est un service de test de charge externe qui utilise sélénium pour contrôler les véritables navigateurs web lors de la lecture de charge arrière.

l'approche nécessite évidemment un tonne plus de matériel que les techniques normales d'essai de charge, mais le matériel est en fait assez bon marché quand vous utilisez le cloud computing. Et un bel effet secondaire de ceci est que le script est beaucoup plus facile que l'essai de charge normale. Vous n'avez pas à faire d'appariement regex avancé (comme JMeter requires) pour extraire les cookies, l'état de session .NET, les paramètres de requête Ajax, etc. Puisque vous utilisez de vrais navigateurs, ils font juste ce qu'ils sont censés faire.

désolé de lancer ouvertement un produit commercial, mais avec un peu de chance le le concept est intéressant pour certaines personnes et les amène au moins à penser à de nouvelles façons de gérer les tests de charge lorsque vous avez accès à un tas de matériel supplémentaire!

j'ai utilisé JMeter . En plus de tester le serveur web, vous pouvez également tester votre backend de base de données, des services de messagerie et des serveurs de courrier électronique.

ab , siège , tsung , httperf , Piétiner , Pylot, demande-log-analyzer , perftools

pour un usage simple, je perfer ab (apache benchmark) et siege, plus tard un est nécessaire car ab ne supporte pas les cookies et créerait des sessions sans fin à partir du site dynamique.

les deux sont simples pour commencer:

ab -c n -t 30 url

siege -b -c n -t 30s url

siege peut fonctionner avec plus d'urls.

dernière version de siège mettre verbose en siegerc, ce qui est agaçant. vous ne pouvez le désactiver qu'en éditant ce fichier( /usr/local/etc/siegerc ).

pour un service basé sur le web, consultez loader.io .

résumé:

chargeur.io est un service de test de charge gratuit qui vous permet de tester vos applications web/API avec des milliers de connexions simultanées.

ils ont aussi un API .

Comme cette question est encore ouverte, je pourrais aussi bien peser.

la bonne nouvelle est qu'au cours des 5 dernières années environ les outils Open Source ont vraiment mûri et décollé dans l'espace, la mauvaise nouvelle est qu'il y en a tellement là-bas.

Voici mes pensées: -

Jmeter vs Grinder

Jmeter est piloté à partir d'une spécification de style XML, qui est construit via une interface graphique.

Grinder utilise les scripts Jython dans un cadre Java multi-threadé, donc plus orienté vers les programmeurs.

les deux outils gèrent HTTP et HTTPS et ont un enregistreur proxy pour vous aider à démarrer. Les deux outils utilisent le modèle de contrôleur pour piloter plusieurs agents de test de sorte que l'évolutivité n'est pas un problème (étant donné l'accès au nuage).

ce qui est mieux: -

un appel difficile que la courbe d'apprentissage est raide avec les deux outils que vous obtenez dans les exigences de script plus compliquées pour la réécriture d'url, la corrélation, la fourniture de données uniques par utilisateur virtuel et la simulation de première fois ou les utilisateurs de retour (en manipulant les en-têtes HTTP).

qui a dit que je commencerais par Jmeter car cet outil a un énorme succès et il y a beaucoup d'exemples et de tutoriels sur le web pour l'utilisation de cet outil. Si et quand vous arrivez à un "blocage de route", c'est quelque chose que vous ne pouvez pas "facilement" faire avec Jmeter alors jeter un oeil à la meuleuse. Le la bonne nouvelle est que ces deux outils ont la même exigence Java et qu'une solution "mix and match" n'est pas hors de question.

quelque chose de nouveau à ajouter – navigateurs Sans Tête exécutant plusieurs instances de WebDriver de sélénium.

il s'agit d'une approche relativement nouvelle parce qu'elle repose sur la disponibilité de ressources qui peuvent maintenant être fournies à partir du nuage. Avec cette approche, un script Selenium (WebDriver) est pris et exécuté dans un navigateur sans tête (i.e. WebDriver = nouveau pilote HtmlUnitDriver()) dans plusieurs threads.

d'après l'expérience, environ 25 instances de 'navigateurs sans tête' peuvent être exécutées à partir de la petite Instance M1 D'Amazon.

ce que cela signifie est que tous les problèmes de corrélation, de réécriture d'url disparaissent pendant que vous réutilisez vos scripts de test fonctionnels pour devenir des scripts de test de performance.

l'évolutivité est compromise car plus de VMs seront nécessaires pour conduire la charge, par rapport à un pilote HTTP tel que le Grinder ou le Jmeter. Cela dit, si vous cherchez à conduire 500 utilisateurs virtuels puis avec 20 Amazon petites Instances (6 cents de l'heure chacun) à un coût de seulement 1,20 $par heure vous donne la charge qui est très proche de l'expérience utilisateur réelle.

aussi, il y a un impressionnant open-source pure-python distribué et évolutif locust framework qui utilise greenlets . C'est excellent pour simuler une énorme quantité d'utilisateurs simultanés.

nous avons récemment commencé à utiliser Gatling pour les essais de charge. Je recommande fortement d'essayer cet outil pour l'essai de charge. Nous avions utilisé SOASTA et JMETER dans le passé. Notre principale raison d'envisager Gatling est la suivante:

• enregistreur pour enregistrer le scénario
• en utilisant Akka et Netty qui donne de meilleures performances comparer à Modèle de filetage Jmeter
• DSL Scala qui est très maintenable comparer à JMeter XML
• facile d'écrire les tests, n'ayez pas peur si c'est scala.
• Reporting

laissez-moi vous donner un exemple simple pour écrire le code en utilisant le code Gatling:

// your code starts here  
val scn = scenario("Scenario")  
     .exec(http("Page")
     .get("http://example.com")) 
// injecting 100 user enter code here's on above scenario.   
setUp(scn.inject(atOnceUsers(100)))       

cependant, vous pouvez le rendre aussi compliqué que possible. Une des caractéristiques qui se démarquent de Gatling est le reporting qui est très détaillé.

voici quelques liens:

Gatling

Gatling Tutoriel

j'ai récemment donné une conférence à ce sujet, vous pouvez passer en revue la discussion ici:

https://docs.google.com/viewer?url=http%3A%2F%2Ffiles.meetup.com%2F3872152%2FExploring-Load-Testing-with-Gatling.pdf

C'est une vieille question, mais je pense que de nouvelles solutions sont dignes d'une mention. LoadImpact check-out: http://www.loadimpact.com .

j'ai essayé WebLoad c'est une très soignée de l'outil. Il est livré avec et tester le script IDE qui vous permet d'enregistrer l'action de l'utilisateur sur un site web. Il dessine également un graphique comme il effectuer des tests de stress sur votre serveur web. L'essayer, je vous le recommande fortement.

en essayant tout ce qui est mentionné ici, j'ai trouvé que chargeur à boucle était le meilleur pour mes besoins. interface très facile, suivi en temps réel, statistiques utiles, à partir desquelles je construis des graphiques de performance. Toutes les fonctionnalités de libcurl sont inclus.

Blaze meter a une extension chrome pour enregistrer les sessions et les exporter vers JMeter (nécessite actuellement une connexion). Vous avez aussi la possibilité de leur payer de l'argent pour l'exécuter sur leur cluster de serveurs JMeter (leur prix semble bien meilleur que Loadumpact que je viens d'arrêter d'utiliser):

• BlazeMeter Chrome Extension
• entrée de Blog à ce sujet

Je n'ai aucune association avec eux, j'aime juste l'apparence de leur service, bien que je n'ai pas encore utilisé la version payée.

vous avez posé cette question il y a presque un an et je ne sais pas si vous êtes encore à la recherche d'un autre moyen d'évaluer votre site web. Toutefois, comme cette question n'est toujours pas marquée comme résolue, je voudrais suggérer le service web gratuit LoadImpact (btw. pas affiliés). Viens de recevoir ce lien via twitter et souhaitez partager cette trouvaille. Ils créent une bonne vue d'ensemble raisonnable et pour quelques dollars de plus vous obtenez le "mode plein impact". Cela semble probablement étrange, mais bonne chance de pousser et de freinage de votre service :)

j'ai trouvé IBM page detailler également un outil intéressant pour travailler avec.

j'ai utilisé openSTA .

cela permet d'enregistrer une session avec un site web et de la relire via un langage de script relativement simple.

vous pouvez facilement tester les services web et écrire vos propres scripts.

il vous permet de mettre des scripts ensemble dans un test de n'importe quelle façon que vous voulez et configurer le nombre d'itérations, le nombre d'utilisateurs dans chaque itération, le temps de montée en puissance pour présenter chaque nouvel utilisateur et le délai entre chaque itération. Des Tests peuvent également être programmés à l'avenir.

c'est open source et gratuit.

il produit un certain nombre de rapports qui peuvent être sauvegardés sur une feuille de calcul. Nous utilisons ensuite un tableau de pivotement pour facilement analyser et représenter graphiquement les résultats.

nous utilisons L'outil Microsoft mentionné - Microsoft Web Application Stress Tool. C'est l'outil le plus facile que j'ai utilisé. Il est limité de nombreuses façons, y compris le fait de ne pouvoir frapper le port 80 que sur des tests créés manuellement. Mais, sa facilité d'utilisation, il est utilisé.

nous complétons la charge de cet outil avec D'autres outils, y compris les araignées OpenSTA et link check.

JMeter semble bon de mon évaluation initiale, j'espère l'inclure dans notre intégration continue va de l'avant. Mais, JMeter est complexe et non trivial à déployer.

je suggère d'ouvrir une autre question concernant l'interprétation des résultats de L'outil d'évaluation du stress lié à la SP.

Visual Studio Test de l'Édition 2010 (2008 bon aussi). C'est un outil très facile et puissant pour créer des tests web/load avec.

le bonus avec cet outil lors de l'utilisation contre les serveurs Windows est que vous obtenez un accès intégré à toutes les statistiques du serveur perfmon dans votre rapport. Vraiment utile.

l'autre bonus est qu'avec Visual Studio project vous pouvez intégrer une" session de Performance " qui va profiler l'exécution de code de votre site web.

si vous servez des pages web à partir d'un serveur windows, c'est le meilleur outil là-bas.

il existe une licence distincte et coûteuse pour l'utilisation de plusieurs machines pour tester la charge de l'application.

nous avons développé un processus qui traite la mesure de la charge et du rendement comme une préoccupation de premier ordre-comme vous le dites, le laisser à la fin du projet tend à conduire à la déception...

ainsi, pendant le développement, nous incluons des tests multi-utilisateurs très basiques (utilisant le sélénium), qui vérifient la folie de base comme la gestion de session cassée, les questions évidentes de concurrence, et les problèmes évidents de ressources de contention. Les projets Non-triviaux incluent ceci dans le processus d'intégration, de sorte que nous obtenons des commentaires très réguliers.

pour les projets qui n'ont pas d'exigences de performance extrêmes, nous incluons des tests de performance de base dans nos tests; Habituellement, nous écrivons les tests en utilisant BadBoy, et les importons dans JMeter, en remplaçant les détails de connexion et d'autres choses spécifiques au fil. Nous les montons ensuite au niveau où le serveur traite 100 requêtes par seconde; si le temps de réponse est inférieur à 1 seconde, c'est généralement suffisant. Nous lancer et de passer avec nos vies.

pour les projets avec des exigences de performance extrêmes, nous utilisons toujours BadBoy et JMeter, mais nous mettons beaucoup d'énergie à comprendre les goulots d'étranglement sur les serveurs de notre plate-forme d'essai(web et serveurs de bases de données, généralement). Il y a un bon outil pour analyser les journaux D'événements de Microsoft qui aide beaucoup avec cela. Nous trouvons généralement des goulots d'étranglement inattendus, que nous optimisons si possible; cela nous donne une application qui est aussi vite que possible sur "1 serveur web, 1 serveur de base de données". Nous nous déployons alors généralement vers notre infrastructure cible, et utilisons l'un des services "Jmeter in the cloud" pour relancer les tests à l'échelle.

encore une fois, les rapports PAL aident à analyser ce qui s'est passé pendant les tests - vous voyez souvent des goulots d'étranglement très différents sur les environnements de production.

la clé est de s'assurer que vous ne faites pas seulement vos tests de stress, mais aussi que vous recueillez les informations dont vous avez besoin pour comprendre les performances de votre application.

Il y a beaucoup de bons outils mentionnés ici. Je me demande si les outils sont une réponse à la question: "Comment testez-vous une application web?"Les outils ne fournissent pas vraiment une méthode pour mettre l'accent sur une application Web. Voilà ce que je sais:

Stress tests montre comment une application Web échoue, tout en servant les réponses à une augmentation de la population d'utilisateurs. Les tests de tension montrent comment l'application Web fonctionne pendant qu'elle échoue. La plupart des applications Web aujourd'hui - en particulier les applications Web sociales/mobiles- sont intégration des services. Par exemple, lors de la panne de Facebook en mai 2011, vous ne pouviez pas vous connecter Pepsi.com ' s Web app. L'application n'a pas entièrement, juste une grosse partie de sa fonction normale deviennent indisponibles pour les utilisateurs.

test de Performance montre la capacité d'une application Web à maintenir les temps de réponse indépendamment du nombre d'utilisateurs qui utilisent simultanément l'application. Par exemple, une application qui gère 10 transactions par seconde avec 10 utilisateurs simultanés doit gérer 20 transactions par seconde à 20 utilisateurs. Si l'application traite moins de 20 transactions par seconde, les temps de réponse augmentent et l'application n'est pas capable d'atteindre une évolutivité linéaire.

de plus, dans l'exemple ci-dessus, le décompte des transactions par seconde ne doit porter que sur les opérations réussies d'un cas d'utilisation/flux de travail d'essai. Les échecs se produisent généralement dans des délais plus courts et rendront la mesure de TPS trop optimiste. Les échecs sont importants pour un test de stress et de performance puisqu'ils génèrent de la charge sur l'application aussi.

j'ai écrit la méthodologie PushToTest dans le guide de L'utilisateur TestMaker à http://www.pushtotest.com/pushtotest-testmaker-6-methodology . TestMaker est disponible en deux versions: Open Source (GPL) version communautaire et TestMaker Enterprise (commercial avec un grand soutien professionnel.)

- Frank

regardez LoadBooster ( https://www.loadbooster.com ). Il utilise headless scriptable browser PhantomJS / CasperJs pour tester des sites web. Phantomjs analyse et rend chaque page, exécute le script côté client. L'approche de navigateur sans tête est plus facile à écrire des scénarios de test pour soutenir la navigation de navigateur Web 2.0 lourd AJAX complexe, clic de souris et des touches dans le navigateur ou d'attendre jusqu'à ce qu'un élément existe dans DOM. LoadBooster support selenium HTML script de trop.

avertissement: je travaille pour LoadBooster.

Essayer ZebraTester qui est beaucoup plus facile à utiliser que jMeter. J'utilise jMeter depuis longtemps, mais le temps total de réglage pour un essai de charge a toujours été un problème. Bien que ZebraTester ne soit pas open source, le temps que j'ai économisé au cours des six derniers mois compense. Ils disposent également d'un portail SaaS qui peut être utilisé pour des essais rapides à l'aide de leurs générateurs de charge.

une note de plus, pour notre application web, j'ai trouvé que nous avions d'énormes problèmes de performance en raison de la discorde entre les threads sur les serrures... la morale était donc de bien réfléchir au système de verrouillage. Nous avons fini par avoir des threads de worker pour étouffer trop de requêtes en utilisant un gestionnaire http asynchrone, sinon l'application serait tout simplement submergée et s'écraserait et brûlerait. Cela signifiait qu'un énorme arriéré pourrait s'accumuler, mais au moins le site resterait en place.

regardez TestComplete .

j'appuie la suggestion d'opensta. Je voudrais juste ajouter que cela vous permet de faire des choses pour surveiller le serveur que vous testez en utilisant SMTP. Nous suivons la charge du processeur, la mémoire utilisée, les byes envoyés, etc. Le seul inconvénient est que si vous trouvez quelque chose de boken et que vous voulez faire une correction, il s'appuie sur plusieurs bibliothèques open-source qui ne sont plus tenues à jour, de sorte que l'obtention d'une version de compilation de la source est plus difficile qu'avec la plupart des logiciels libres.

j'ai joué avec JMeter. On pense qu'il ne pouvait pas ne pas tester était ASP.NET Webforms. Le viewstate a cassé mes tests. Je ne suis pas shure pourquoi, mais il ya un couple d'outils là-bas qui ne poignée de viewstate droit. Mon projet actuel est ASP.NET MVC et JMeter s'en sortent bien.

j'ai eu de bons résultats avec FunkLoad :

• facile de script interaction de l'utilisateur
• les rapports sont clairs
• peut surveiller la charge du serveur

au risque d'être accusé de promotion honteuse de soi, je tiens à souligner que dans ma quête d'un outil d'essai de charge libre je suis allé à cet article: http://www.devcurry.com/2010/07/10-free-tools-to-loadstress-test-your.html

soit je n'ai pas pu obtenir le débit que je voulais, soit je n'ai pas pu obtenir la flexibilité que je voulais. Et j'ai voulu facilement agréger les résultats de plusieurs serveurs de génération de charge dans l'analyse post-test.

j'ai essayé tous les outils sur la liste et à ma frustration trouvé qu'aucun d'eux tout à fait fait ce que je voulais être en mesure de faire. Alors j'en ai construit un et je le partage.

le voici: http://sourceforge.net/projects/loadmonger

PS: Pas de commentaires sarcastiques sur le nom de gens qui sont familiers avec l'argot urbain. Je n'étais pas mais je suis un peu plus mondain maintenant.

je vote pour jMeter moi aussi et je veux ajouter quelques citations à la réponse de @PeterBernier.

la question principale que les réponses d'essai de charge est combien de concurrents les utilisateurs peuvent-ils prendre en charge mon application web? Afin d'obtenir une réponse adéquate, l'essai de charge doit représenter l'utilisation réelle de l'application, aussi près que possible .

Garder au-dessus à l'esprit, jMeter a de nombreux blocs de construction Logique Contrôleurs , Config Éléments , Pré Processeurs , Auditeurs ,... qui peut vous aider dans cette.

vous pouvez imiter la situation réelle avec jMeter, par exemple vous pouvez:

1. configurer jMeter pour agir comme un vrai navigateur en configurant ( concurrent resource download , browser cache , http headers , setting request time out , cookie management , https support , encoding , ajax support ,... )
2. configurer jMeter pour générer des requêtes Utilisateur (en définissant number of users per second , ramp-up time , scheduling ,...)
3. Configurer beaucoup de client avec jMeter sur eux, pour faire une répartition de la charge d'essai.
4. traite la réponse pour trouver si le serveur répond correctement pendant le test. ( Par exemple assert réponse de trouver un texte)

s'il vous Plaît prendre en considération:

• il est facile de démarrer un vrai test d'application web avec jMeter en quelques minutes. Le jMeter dispose d'un outil très simple qui enregistre votre scénario de test ( connu sous le nom de HTTP(S) Test Script Recorder ).
• jMeter a beaucoup de plugins à http://jmeter-plugins.org .
• le JMeter UI est basé sur swing et a fait de bons changements dans jmeter 3.2. Sur l'autre main veuillez considérer que JMeter GUI ne doit être utilisé que pour le test et le débogage. Ce n'est pas une bonne pratique de l'utiliser en mode GUI pour un test réel. https://www.blazemeter.com/blog/5-ways-launch-jmeter-test-without-using-jmeter-gui . Configurer et tester votre scénario et l'exécuter en mode non-gui.
• il y a beaucoup de rapports montrant des outils en jMeter (connu sous le nom listeners ), mais il n'y a pas censé être sur pendant l'essai. Vous devez exécuter votre test et générer rapports (fichiers .jtl ). Ensuite, vous devez utiliser ces outils pour analyser le résultat. S'il vous plaît jeter un oeil à https://www.blazemeter.com/blog/jmeter-listeners-part-1-basic-display-formats ou https://www.tutorialspoint.com/jmeter/jmeter_listeners.htm .

The https://www.blazemeter.com/jmeter a de très bonnes informations pratiques pour vous aider à configurer votre environnement de test.