Load testing from Windows Azure | Tests de charge depuis Windows Azure

 

English	Français
Stéphane Crozatier, a colleague of mine, built a solution to make it simple to use Visual Studio and Azure to stress test an application.	Stéphane Crozatier, un de mes collègues, a élaboré une solution qui simplifie l’utilisation de Visual Studio Azure pour tester en charge une application.
This post is about Stéphane’s solution. It’s made of the following parts: - Visual Studio 2010 load tests - What Stéphane’s solution does - How to use Stéphane’s solution	Ce billet est à propos de la solution de Stéphane. Nous allons aborder les points suivants: - les tests de charge avec Visual Studio 2010 - ce que la solution de Stéphane fait - comme utiliser la solution de Stéphane
A summary of the post is also available	Un résumé de ce billet est également disponible

(load test rig = banc de test, application under test = application testée)

 

Visual Studio 2010 load tests	Les tests de charge avec Visual Studio 2010
With Visual Studio 2010 Utimate with MSDN, you can reuse unit tests or performance tests for your load tests. Moreover, since March 2011, Visual Studio 2010 Ultimate with MSDN subscribers can use an unlimited number of virtual users. When needing more users you’ll need additional injecters (the agents) and a controller for the coordination of those agents. Your Visual Studio 2010 IDE will connect to that test rig in order to tell which tests must be executed and get the results.	Avec Visual Studio 2010 Utimate with MSDN, on peut réutiliser des tests unitaires ou des tests de performance pour les tests de charge. Par ailleurs, depuis mars 2011, les abonnés à Visual Studio 2010 Ultimate with MSDN bénéficient d'un nombre illimité d'utilisateurs virtuels. Si l’on a besoin de plus d’utilisateurs virtuels, on a également besoin de plus d’injecteurs (les agents) ainsi que d’un contrôleur pour la coordination de ces agents. L’IDE Visual Studio 2010 se connectera au banc de test de façon à indiquer quels tests doivent être exécutés et récupérer les résultats.
This Visual Studio Magazine article gives you an overview of how this works.	Cet article de Visual Studio Magazine donne une vue d’ensemble de la façon dont cela fonctionne.
As you need lots of agents, having virtual machines only for the time of the test is interesting, and using Windows Azure public cloud is a good idea.	Lorsqu’on a besoin de beaucoup d’agents, disposer des machines virtuelles uniquement pendant le temps du test est intéressant, et utiliser le cloud public Windows Azure est une bonne idée.

What Stéphane’s solution does	Ce que la solution de Stéphane fait
Stéphane’s solution (AzureLoadTest) automates the provisioning and configuration of the load test rig in Azure against which the local Visual Studio 2010 IDE can connect in order to deploy the tests, have them executed and get the results.	La solution de Stéphane (AzureLoadTest) automatise le mise à disposition et la confguration du banc de test sur Azure, banc sur lequel l’IDE local Visual Studio 2010 peut se connecter de façon à déployer les tests, les faire exécuter, et récupérer les résultats.

(on premises = à demeure)

Agents are deployed in a multi instance worker role (one instance per agent), and the controller is deployed in a mono instance worker role. The big advantage over VM role is that you only have to maintain the code that configures the environment, not the environment itself. For instance, worker roles OS can be automatically patched by Windows Azure.	Les agents sont déployés dans un worker role multi instances (une instance par agent), et le contrôleur est déployé dans un worker role mono instance. Le gros avantage par rapport à des VM roles est qu’on a uniquement à maintenir le code qui configure l’environnement, pas l’environnement lui-même. Par exemple, l’OS des worker roles peut être automatiquement patché par Windows Azure.
The controller worker role only has one instance so there is a single point of failure here (SPOF) which is accepted. Should the instance of the controller fail while a load test is running, the test has to be run again. Although Windows Azure does not guarantee any uptime on a single instance (only multi instance roles have SLAs), in practice, an instance does not fail often.	Le worker role du contrôleur n’a qu’une instance et il y a donc là un point unique de faiblesse (SPOF en anglais) qui est assumé. Si l’instance du contrôleur tombait pendant l’exécution d’un test, il faudrait refaire le test. Bien que Windows Azure ne garantit pas le temps de bon  fonctionnement d’une instance unique (seules les rôles avec plusieurs instances sont soumis à SLA), en pratique, une instance ne tombe pas souvent.
Most of the value of the code contained in the solution, is in the architecture of the deployment, and the numerous tests to make it work. Of course, the value is also and mainly to have a working solution!	La valeur du code contenu dans cette solution  réside principalement dans l’architecture du déploiement, et les nombreux tests qui ont été nécessaires à son élaboration. Bien sûr, la valeur réside aussi et surtout dans le fait d’avoir une solution qui fonctionne!
I won’t go into the details of the code here. Should you have questions, please leave a comment and Stéphane or I will answer it.	Je ne vais pas rentrer dans les détails du code ici. Si vous avez des questions, n’hésitez pas à laisser un commentaire et Stéphane ou moi y répondrons.
In terms of architecture, the application under test can be anywhere on the Internet. The agents and the controller communicate thru direct IP V4 communication (when the controller has started, it hosts a WCF service. When the agents start, they try to connect to that WCF service until they succeed, then they register to the controller). The controller and Visual Studio are connected thru Azure Connect which encapsulates IP V6 traffic in an IPSec based Virtual Private Network (VPN). For authentication purposes, all the machines (agents, controller, Visual Studio) share a common username/password. This username/password, as often in Azure, is the one used by the remote desktop access plug-in. You don’t need to reuse the same user as your local Windows session, but if this is not the case, you need to run Visual Studio as that user which was configured in Azure.	En termes d’architecture, l’application à tester peut être n’importe où sur Internet. Les agents et le contrôleur communiquent via une communication directe en IP V4 (quand le contrôleur a fini de démarrer, il héberge un service WCF. Quand les agents démarrent, ils tentent de se connecter au service WCF jusqu’à ce qu’ils y arrivent, puis ils s’enregistrent auprès du contrôleur). Le contrôleur et Visual Studio sont connectés via Azure Connect qui encapsule un trafic IP V6 dans un réseau privé virtuel (VPN) à base d’IPSec. Pour l’authentification, toutes les machines (agents, contrôleurs, Visual Studio) partagent un même nom d’utilisateur/mot de passe. Ce nom d’utilisateur/mot de passe, comme souvent avec Azure, est celui utilisé par le plug-in d’accès au bureau à distance. Il n’est pas nécessaire de réutiliser le même compte que la session Windows locale, mais si ce n’est pas le cas, il faudra exécuter Visual Studio en tant que ce compte configuré dans Azure.

 

How to use Stéphane’s solution	Comment utiliser la solution de Stéphane
Prerequisites	Pré-requis
The prerequisistes are the following: - a Windows Azure account that has access to the Windows Azure Connect Beta Program - a Visual Studio 2010 load testing key. This can be found in your MSDN subscription. Go to https://go.microsoft.com/fwlink/?LinkID=207267, and click on the “Product Keys” button	Les pré-requis sont les suivants: - un compte Windows Azure qui a accès à la bêta de Windows Azure Connect - Une clef de licence pour les tests de charge Visual Studio 2010. On la trouve dans l’abonnement MSDN. Il suffit d’aller à https://go.microsoft.com/fwlink/?LinkID=207267, et de cliquer sur le bouton d’obtention des clefs produits.

you will also need - a Windows Azure development environment that you can setup from https://www.microsoft.com/windowsazure/. Note that it may also be possible to reuse the package without recompiling it, but since you’ll need Visual Studio 2010 for the test anyway, having Azure development environment is really not a big deal. - a Windows Azure storage account where you will store the zip files containing the setup packages for the agents and the controller - a utility like 7-Zip to extract files from ISO and EXE archives. - a utility like Azure Storage Explorer to upload files to an Azure storage account.	Il faut aussi avoir - un environnement de développement Windows Azure que l’on peut configurer à partir de https://windowsazure.fr. Il est à noter qu’il doit être possible de réutiliser un package tout fait à partir de la solution de Stéphane, mais comme on a de toutes façons besoin de Visual Studio 2010 pour effectuer les tests de charge, avoir également l’environnement de développement Azure n’est plus très compliqué. - un compte de stockage Windows Azure où l’on stockera les fichiers zip contenant le setup des agents et du contrôleur. - un utilitaire tel que 7-Zip pour extraire des fichiers d’une archive ISO ou EXE. - un utilitaire tel que Azure Storage Explorer pour charger des fichiers dans le compte de stockage Windows Azure
Prepare the solution and the local environment	Préparer la solution et l’environnement local
Download the solution from https://aka.ms/w3ypbi, unzip it, and open it in Visual Studio.	Télécharger la solution depuis https://aka.ms/w3ypbi, la dézipper, et l’ouvrir dans Visual Studio.
From the local Visual Studio 2010 workstation, acces the Windows Azure Management portal and go to Virtual Network, Azure Connect and click on Install local EndPoint (more on this in MSDN)	Depuis la machine locale avec Visual Studio 2010, accéder au portail de gestion Windows Azure et aller à Virtual Network, Azure Connect et cliquer sur Install local EndPoint (plus d'info sur MSDN)

Once the local endpoint is installed, create a group called “VS load test” and add the endpoint into it. For a local Visual Studio 2010 workstation named DMO1001A, you should see:

Une fois que le point de terminaison local est installé, créer un groupe appelé “VS load test” et y ajouter le point de terminaison. Pour une machine locale appelée DMO1001A, on doit avoir:

Also get the Activation token from the Windows Azure Management portal and replace #your-activation-token# by this value in the AzureLoadTest\AzureLoadTest\ ServiceConfiguration.cscfg file.

Récupérer également le jeton d’activation dans le portail de gestion Windows Azure et remplacer #your-activation-token# par cette valeur dans le fichier AzureLoadTest\AzureLoadTest\ ServiceConfiguration.cscfg

 

Enter the Visual Studio 2010 load testing key in the AzureLoadTest\AzureLoadTest\ ServiceConfiguration.cscfg file in the line starting with <Setting name="TestController_License" value=	Entrer la clef de licence Visual Studio 2010 pour les tests de charge dans le fichier AzureLoadTest\AzureLoadTest\ ServiceConfiguration.cscfg, au niveau de la ligne qui commence par <Setting name="TestController_License" value=
In the same file, replace #your-storage-account-name# by your storage account name.	Toujours dans le même fichier, remplacer #your-storage-account-name# par le nom du compte de stockage.
Configure remote desktop access so that you have a username and password. You might want to read more on how to do that in MSDN Library. As an example, you might want to create a user with a username of loadtester and a password of “ANpcs_fsdd10”. Note that  the code does not manage any type of character as the password is included in some command lines used by the agents and controller setup. For instance, having a slash in the password may result in installation failure.	Configurer l’accès au bureau à distance de façon à disposer d’un nom d’utilisateur / mot de passe. On trouvera plus d’info sur le sujet dans la librairie MSDN. Par exemple, on peut vouloir créer un utilisateur loadtester avec un mot de passe “ANpcs_fsdd10”. A noter que le code ne gère pas tous les types de carcactères spéciaux étant donné que le mot de passe est inclus dans certaines lignes de commande lors de l’automatisation de l’installation des agents et du contrôleur. Par exemple, avoir un slash (/) dans le mot de passe peut faire échouer la solution.

 

 

This user must also be created locally so that you can run Visual Studio as this user. You also need to give the user the right permissions in order to be able to run Visual Studio under that account. Creating the local user can be done in the following way for instance on Windows Server 2008 R2:

Cet utilisateur doit aussi être créé localement de façon à pouvoir exécuter Visual Studi en tant que cet utilisateur. Il est également nécessaire de donner les droits nécessaires au compte de façon à ce qu’il puisse exécuter Visual Studio. La création du compte local peut être faite comme suit par exemple sur Windows Server 2008 R2:

 

You will also need to create 3 zip files that will be used to install the load agents, the controller and SQL Server Express.	Il va également falloir créer 3 fichiers zip qui seront utilisés pour installer les agents, le contrôleur et SQL Server Express.
Download SQL Server 2008 R2 Express 64 bit in English from Microsoft Web Site. you’ll get a file named SQLEXPRWT_x64_ENU.exe that you can open with 7-Zip in order to repackage it as a Zip File (extract from EXE, then Zip) named SQLEXPRWT_x64_ENU.zip (NB: this will be case sensitive once in the Windows Azure blob)	Télécharger SQL Server 2008 R2 Express 64 bit en anglais depuis le site Web de Microsoft. On obtient un fichier appelé SQLEXPRWT_x64_ENU.exe que l’on peut ouvrir avec 7-Zip de façon à le repackager en tant que fichier zip (extraire le contenu de l’EXE, puis le zipper) appelé SQLEXPRWT_x64_ENU.zip (NB: ce nom sera sensible à la casse un fois dans un blob Windows Azure)

Then upload that file to an Azure blob storage container with Azure Storage Explorer or another tool. The container must be public as the code does not provide credentials while downloading it on the worker role instances.

Puis charger ce fichier dans un conteneur de blob Azure avec Azure Storage Explorer ou tout autre outil équivalent. Le conteneur doit être public puisque le code ne fournit pas de crédentités pendant qu’il récupère le fichier dans les instances de worker roles.

 

Download Visual Studio Agents 2010 – ISO from Microsoft Web Site. You’ll get a file named X16-49583VS2010Agents1.iso that you can open with 7-Zip.

Télécharger l’ISO Visual Studio Agents 2010 du site Web de Microsoft. On obtient un fichier appelé X16-49583VS2010Agents1.iso qu’on peut ouvrir avec 7-Zip.

Extract and zip as testagent.zip the content of testagent folder. Extract and zip the testcontroller folder a testcontroller.zip Warning: the zip files must contain setup.exe at their respective roots.

Extraire et zipper en tant que testagent.zip le contenu du répertoire testagent. Extraire et zipper en tant que testcontroller.zip le contenu du répertoire testcontroller. Attention: les fichier zip doivent avoir le fichier setup.exe juste à leur racine.

 

upload the two files in the public Windows Azure storage container.

charger les deux fichiers dans le conteneur public du Windows Azure storage.

 

Run a load test	Exécuter un test de charge
In order to deploy the test rig, publish AzureLoadTest to Windows Azure.	Pour déployer le banc de test, publier AzureLoadTest dans Windows Azure.

NB: If the instances are stuck in a “wait for role to start” status for more than 30 minutes, check if the configuration is OK (the 3 zip files URI, the Azure Connect Activation token, the Visual Studio 2010 load test license).	NB: si les instances sont bloquées dans un état “wait for role to start” pendant plus de 30 minutes, vérifier si la configuration est correcte(les URI des 3 fichiers zip, le jeton d’activation Azure Connect, la license Visual Studio 2010 pour les tests de charge).

After 10 to 15 minutes, you should get this:

Après 10 à 15 minutes, vous devriez avoir cela:

Let’s now connect the local Visual Studio with the test rig. First, Visual Studio 2010 needs to run locally as the loadtest user. If your local session is not with that user, then you must use runas. Here is an example:	Il est alors temps de connecter Visual Studio au banc de test. Premièrement, Visual Studio 2010 a besoin de s’exécuter en local en tant que le compte loadtester. Si la session Windows locale n’est pas avec cet utilisateur, alors il faut utiliser runas. Voici un exemple:

We also need the local machine to be connected thru Azure Connect to the test rig. For that, in the management portal, Virtual Network, Azure Connect, Groups and Roles, click “Refresh Role Information” and you should see the controller

On a également besoin que la machine locale soit connectée via Azure Connect au banc de test. Pour cela, dans le portail de gestion, rubriques Virtual Network, Azure Connect, Groups and Roles, cliquer sur “Refresh Role Information” de façon à voir le contrôleur

Edit the Controller group and add VS Load Test

Editer le groupe Controller et y ajouter VS Load Test

(…)

Copy the name of the controller role instance in the clipboard (RD00155D3A0733 in this example) Check that everything is OK in the Systray. You should be able to ping the controller instance (RD00155D3A0733 in this example)

Copier le nom de l’instance du rôle controller dans le presse papier (RD00155D3A0733 dans cet exemple) Vérifier que tout est OK dans la barre de tâche en bas à droite. A ce stade, on doit pouvoir pinguer l’instance du rôle controller (RD00155D3A0733 dans notre exemple)

From Visual Studio 2010 running as loadtester, go to the manage Test Controllers menu item

Depuis Visual Studio 2010 qui s’exécute en tant que loadtester, aller dans l’entrée de menu “manage Test Controllers”

Then, it is possible to create a test project, add web tests, and create a load test. The exact details of this are beyond the scope of this blog post. Here are a few screen shots of what you get with Stéphane’s solution, as you use the Azure test rig (in this sample I test another solution hosted in Azure too).

Il est alors possible de créer un projet de test, ajouter des tests Web, et créer un test de charge.Les détails de cette manipulation sont en dehors du cadre de cet article. Voici quelques copies d’écrans de ce que l’on obtient avec la solution de Stéphane, pendant qu’on utiliser le banc de test Azure (dans cet exemple, je teste une autre solution également hébergée dans Azure).

Benjamin

Comments

• Anonymous
  October 11, 2011
  Un commentaire utile de Mr Etienne T. Merci à lui:Salut à vous deux,J'ai eu un petit pépin lors de l'utilisation de votre solution j'ai duchangé 2 lignes de codeDans le projet Controlleur --> TestControllerInstaller.csLigne 43             string file = Path.Combine(UnpackPath,"testcontroller\setup.exe");Ajout de testcontroller\ (parce que le unzip en fait ajoute le nom dufichier dans son path.Controlleur --> SQLExpressInstaller.csLigne 53           string file = Path.Combine(UnpackPath,"SQLEXPRWT_x64_ENU\setup.exe");Même chose dans le projet Agent --> TestAgentInstaller.csLigne 42            string file = Path.Combine(UnpackPath,"testagent\setup.exe");Après ces changements, tout a fonctionné comme prévu dans le billet.Merci d’avoir tout documenté la procédure, c'est excellent!!Salut,Etienne