Visual Studio contient depuis quelques versions une fonctionnalité de test de charge des applications web. Cet article contient une description de haut niveau des fonctionnalités de la version Visual Studio 2013 Ultimate ainsi que quelques éléments de comparaison avec HP LoadRunner.
Niveau de protocole
Si on avait à comparer avec LoadRunner, le protocole (dans le sens LoadRunner) serait HTTP (URL based). Il existe une possibilité de coder une script au niveau de l’interface (« Coded UI test » que l’on pourrait comparer au mode TruClient), mais cela est déconseillé par la documentation. Microsoft en parle comme d’une solution temporaire ou de dernier recours. A mon avis, cela ne doit pas très bien marcher ou consommer une énorme quantité de ressources système.
Enregistreur de script
Un add-in Internet Explorer permet d’enregistrer les actions de l’utilisateur d’une application web compatible avec IE. Ce qui est enregistré sont les actions effectuées au niveau du protocole HTTP (GET, POST…) et pas les actions au niveau du réseau ou utilisant un autre protocole. Par exemple, les interactions d’une applet Java en RMI ne seront pas enregistrées (si tant est que cela existe encore).
Si certaines actions n’ont pas été capturées par l’add-in, il est possible de les ajouter dans le modeleur graphique du script ou de les coder manuellement dans le code source généré (voir plus loin).
Il y a une fonctionnalité de détection des paramètres dynamiques, mais je ne l’ai jamais vu détecter quoi que ce soit durant mes tests. Elle est déclenchée suite à l’enregistrement du script ou à la demande. Elle n’est pas vraiment comparable à la fonctionnalité de corrélation automatique de LoadRunner qui a un taux de détection plus élevé.
Scripting
Une fois le script enregistré, on a accès à un modeleur (je l’appellerai comme ça dans la suite de l’article afin de le différencier d’un script codé) qui permet de modifier le script graphiquement. Par exemple, coupler les paramètres http à une source de données :
On peut convertir ce script en code C# ou Visual Basic (selon la nature du projet .Net). Ce qui ouvre toutes les possibilités du Framework .Net. Voici un court extrait de code:
WebTestRequest request2 = new WebTestRequest("http://localhost/opencart/index.php");
request2.Headers.Add(new WebTestRequestHeader("Referer", "http://localhost/opencart/"));
request2.QueryStringParameters.Add("route", "product/category", false, false);
request2.QueryStringParameters.Add("path", "20_26", false, false);
yield return request2;
request2 = null;
SLA et transactions
Ce qu’il est possible de faire:
- Il est possible de grouper une ou plusieurs requêtes HTTP au sein de transactions.
- Il est possible de définir des temps de réponse attendus globaux ou au niveau des requêtes.
- Il n’est pas possible de définir des SLA par palier de charge ou sur d’autres objectifs.
Dans cet exemple d’exécution, on remarque un dépassement des objectifs :
Paramètres / Jeu d’essai
Il est possible de définir une source de données et de l’utiliser dans le modeleur ou dans le code. Cependant, cette fonctionnalité n’est pas comparable à celle de LoadRunner. Ainsi il n’est pas possible graphiquement :
- D’asservir deux variables (« same line as »).
- D’allouer des blocs de données par utilisateur virtuel.
- De définir des règles de consommation des données (choix d’une ligne au hasard, consommation unique, arrêter en fin de table…).
Tous ces cas d’usage devront être codés (voir plus loin avec les possibilités d’extension).
Think time
Les temps de pause sont liés aux requêtes HTTP et ils se configurent donc au niveau de la requête. Par exemple dans le code généré suivant :
WebTestRequest request1 = new WebTestRequest("http://localhost/opencart/index.php");
request1.ThinkTime = 8;
On peut ensuite définir au niveau du scénario ce que l’on fera de ces temps d’attente (« as recorded », etc.).
Possibilités d’extension
Comme nous l’avons vu précédemment, les scripts peuvent être convertis en code .Net. On peut avoir accès à une API de test de performance depuis ce code. Ce qui permet de gérer plus finement les paramètres ou les différents objets de test (requêtes HTTP, règle de validation ou d’extraction…). Il existe deux API :
- Web Performance Test API : http://msdn.microsoft.com/en-us/library/ms182558(v=vs.120).aspx
- Load Test API : http://msdn.microsoft.com/en-us/library/ms182605(v=vs.120).aspx
Si vous venez de LoadRunner, ce qu’il faut comprendre, c’est que les deux modèles sont cloisonnés (Script : Web Performance Test API et Scénario : Load Test API). Ainsi, on ne peut pas aisément obtenir une information contextuelle au tir dans une instance de script (par exemple, le numéro d’itération dans le tir ou est-on dans un contexte de tir ou pas – e.g. dans LR en jouant sur la valeur de « Group Name »). Il faut coder !
Il y a deux possibilités de création de plugin :
- Load Test Plug-In (http://msdn.microsoft.com/en-us/library/ms243153(v=vs.120).aspx): Pour déclencher des actions à certains évènements du tir (début, fin, dépassement de SLA…). Un exemple simple serait de déclencher des actions en début ou en fin de tir.
- Web Performance Test Plug-In (http://msdn.microsoft.com/en-us/library/ms243191(v=vs.120).aspx): Pour étendre les capacités du modeleur graphique (personnaliser le script sans coder). Ou pour créer du code réutilisable. Un exemple simple serait de générer un nombre aléatoire afin de l’utiliser en tant que paramètre.
Collecte des indicateurs
Cette fonctionnalité est clairement orientée Microsoft. Ainsi, elle est seulement capable de collecter les indicateurs via WMI (ceux qui sont visibles depuis perfmon.exe). Elle ne supporte pas la collecte via SNMP ou rpc.rstatd. Cependant, il y aurait des possibilités (http://www.networkcircus.com/articles/20090606.html) que je n’ai pas testées :
- Le projet Open Pegassus a développé un utilitaire WMI Mapper https://collaboration.opengroup.org/pegasus/
- Il y aurait un client WMI pour Linux http://www.krenger.ch/blog/wmi-commands-from-linux/
- Créer un indicateur personnalisé, comme expliqué dans le paragraphe suivant.
D’un autre côté, cette intégration au monde Microsoft permet de bénéficier d’indicateurs par défaut sur les outils maison (IIS, SQL Server…).
Créer un indicateur personnalisé
Comme expliqué dans le paragraphe précédent, hormis les indicateurs de comportement du test de charge, tous les autres indicateurs ne peuvent provenir que de WMI. Si vous souhaitez créer des indicateurs personnalisés (issu d’une application, d’une extraction, etc.) il faut donc créer une nouvelle section et de nouveaux indicateurs WMI. Une solution est fournie ici http://stackoverflow.com/a/17117685
Scénario
Les possibilités sont à peu près les mêmes qu’avec les outils concurrents. Il existe une fonctionnalité de mix des types de réseau (débit) et des navigateurs (user-agent). Les notions de pacing, durée (ou nombre d’itérations) et de rampe sont présentes par contre les utilisateurs virtuels sont arrêtés d’un coup.
On peut également diminuer ou augmenter la fréquence d’échantillonnage des indicateurs collectés. Ce qui est sympa si on souhaite avoir une granularité plus fine ou si on veut, au contraire, limiter le stress sur les machines testées ou les agents (i.e. les injecteurs). En effet, certains indicateurs sont chers à obtenir en termes de ressources.
Résultats et Reporting
L’outil génère les graphiques classiques des tests de charge (temps de réponse moyen, taux d’erreurs, hits/s…) ainsi que les métriques systèmes via WMI. On peut même faire des calculs d’estimation de la répartition temps serveur / temps réseau, parce qu’il expose les indicateurs :
- Temps réseau : Avg. Connection Wait Time
- Temps réseau (début du transfert) : Avg. First Byte Time
- Temps global (requête + transfert) : Avg. Response Time
Exports Excel
À condition que vous ayez lancé VS2013 en tant qu’administrateur, l’outil est capable de générer deux types de rapport Excel :
- Un rapport de tendance (suivi des performances à travers plusieurs tirs). Un exemple ici.
- Un rapport de comparaison entre différents tirs. Un exemple ici.
Je regrette que les graphiques du type « Over time » (comportement du système durant le tir) ne soit pas directement exportables sous la forme dans laquelle ils sont consultables dans VS2013 (il faut exporter les données du graph, puis reconstruire le graphique depuis Excel). Par exemple, le nombre de hits/s pour savoir si le système s’effondre ou pas :
Infrastructure de test
Il est possible de déporter l’exécution des différents composants sur plusieurs machines :
- Le contrôleur est le composant qui est le chef d’orchestre du tir. Il est aussi chargé de collecter tous les indicateurs et évènements du tir.
- Les « Tests agents » (qu’on appelle injecteur ou Load Generators sur d’autres outils) sont en charge d’exécuter les scripts (ou tests) qui génèrent de la charge sur l’application à tester.
Par défaut, les indicateurs de base (CPU, mémoire réellement disponible) sont ramenés dans le rapport du tir. Ainsi, on peut savoir si l’infrastructure de test tenait la route.
Cloud-based performance testing
Avec l’édition Visual Studio 2013 Ultimate MSDN, il serait possible de tester les sites Internet depuis le cloud et cela serait inclut dans le prix. Voir http://tfs.visualstudio.com/en-us/learn/load-testing
Cependant, il n’y a pas encore assez d’informations sur les éventuels coûts directs (et cachés) et les limites du système lorsque l’on sortira de la phase de Preview. En tout cas, les rapports sont moins riches que lors d’une exécution dans un intranet. Sont absentes par exemple les données système (CPU, mémoire…) ou les données avancées sur le réseau (temps de connexion, premier octet dans le buffer…).
Conclusion
Cet outil ne serait disponible qu’avec Visual Studio 2013 Ultimate MSDN (pour information, le prix public de Visual Studio 2012 Ultimate était de 16 944 €). Il n’y a pas de limite quant au nombre d’utilisateurs simulés (en termes de licence), contrairement aux autres outils de tests de charge où le coût peut être fonction du protocole utilisé (ici il n’y a que le protocole web) et/ou du nombre d’utilisateurs simulés.
Il est difficile de situer l’outil par rapport à la concurrence. Il est plus simple que JMeter (ou tsung). Il supporte moins de protocoles que JMeter, mais il est plus puissant si le système sous test est dans le monde Microsoft. Par contre, il n’est pas encore à la hauteur des solutions propriétaires spécialisées comme LoadRunner ou Borland/Microfocus.
Pour aller plus loin
- Le point d’entrée de la documentation.
- Télécharger la Preview de Visual Studio 2013.