Considérations relatives aux tests de charge
Cette rubrique fournit des conseils pour exécuter des tests de grande charge dans Visual Studio Ultimate. Les sujets abordés sont les suivants :
Choix du modèle de charge approprié
Choix du modèle de connexion approprié
Taux d'échantillonnage et collecte de données
Temps de réflexion
Définition des objectifs de temps de réponse pour des requêtes de tests de performances de site Web
Inclusion de détails de minuterie pour collecter des données de centile
Définition de la propriété Pourcentage de nouveaux utilisateurs
Activation du profileur ASP.NET
Activation de l'enregistrement d'utilisateur virtuel
Activation du traçage SQL
Gestion d'un nombre approprié d'ordinateurs agents
Choix du modèle de charge approprié
Il existe trois types de modèles de charge : constante, par étape et en fonction des objectifs. Pour choisir le modèle de charge approprié pour votre test de charge, vous devez connaître les avantages de chaque type. Pour plus d'informations, consultez Modification des modèles de charge en modèle d'activités des utilisateurs virtuels.
Constante |
Un modèle de charge constante est utile lorsque vous souhaitez exécuter votre test de charge avec la même charge utilisateur pendant une longue durée. Si vous spécifiez une charge utilisateur élevée avec un modèle de charge constante, il est recommandé de spécifier également une période de préchauffage pour le test de charge. Lorsque vous spécifiez une période de préchauffage, vous évitez d'accentuer la contrainte sur votre site en ayant des centaines de nouvelles sessions utilisateur qui atteignent le site en même temps. |
Étape |
Le modèle de charge par étape est l'un des modèles les plus courants et utiles, parce qu'il vous permet de surveiller les performances de votre système à mesure que la charge utilisateur augmente. La surveillance de votre système à mesure que la charge utilisateur augmente vous permet de déterminer le nombre d'utilisateurs qui peuvent être pris en charge avec des temps de réponse acceptables, ou inversement, le nombre d'utilisateurs à partir duquel les performances deviennent inacceptables. Si chaque étape ajoute un grand nombre d'utilisateurs, par exemple, plus de 50 utilisateurs, pensez à utiliser la propriété Durée de démarrage de l'étape pour échelonner le démarrage des utilisateurs dans l'étape. Pour plus d'informations, consultez Comment : spécifier la propriété de la durée de démarrage de l'étape d'un modèle de charge par étape. |
En fonction des objectifs |
Le modèle de charge en fonction des objectifs est similaire à un modèle de charge par étape dans la mesure où la charge utilisateur augmente généralement avec le temps, mais il vous permet de spécifier que la charge doit cesser d'augmenter lorsqu'un compteur de performance atteint un certain niveau. Par exemple, vous pouvez utiliser un modèle de charge en fonction des objectifs pour laisser la charge augmenter jusqu'à ce que l'un de vos serveurs cibles soit occupé à 75 %, puis maintenir la charge fixe. |
Si aucun modèle de charge prédéfini ne répond à vos besoins, il est également possible d'implémenter un plug-in de test de charge personnalisé qui contrôle la charge utilisateur pendant l'exécution des tests de charge. Pour plus d'informations, consultez Création et utilisation de plug-ins personnalisés pour les tests de charge et les tests de performances de site Web.
Choix du modèle approprié de connexion des tests de performances de site Web
Les paramètres d'exécution des tests de charge prennent en charge différentes options pour modéliser les connexions utilisateur en fonction du serveur Web à l'aide de la propriété Modèle de connexion de test Web. Il existe trois types de modèle de connexion : la connexion par utilisateur, le pool de connexions et la connexion par itération de test. Pour choisir le modèle de connexion approprié pour votre test de charge, vous devez connaître les avantages de chaque type.
Connexion par utilisateur |
Le modèle de connexion par utilisateur simule assez fidèlement le comportement d'un vrai navigateur. Chaque utilisateur virtuel qui exécute un test de performances de site Web utilise jusqu'à 6 connexions sur chaque serveur Web. La connexion reste ouverte pour le serveur Web dédié à cet utilisateur virtuel. La première connexion est établie lorsque la première requête du test de performances de site Web est émise. D'autres connexions peuvent être utilisées lorsqu'une page contient plusieurs requêtes dépendantes ; ces requêtes peuvent être publiées en parallèle à l'aide des autres connexions. Les navigateurs plus anciens utilisent jusqu'à deux connexions par serveur Web, mais FireFox 3 et Internet Explorer 8 utilisent jusqu'à 6 connexions par serveur Web. Ces mêmes connexions sont réutilisées pour l'utilisateur virtuel dans tout le test de charge. L'inconvénient du modèle de connexion par utilisateur est que le nombre de connexions ouvertes sur l'ordinateur agent peut être six fois plus élevé que la charge d'utilisateur, ou même encore plus élevé si cela concerne plusieurs serveurs Web, et les ressources requises pour prendre en charge ce nombre élevé de connexions peuvent limiter la charge utilisateur disponible à partir d'un seul agent de test de charge. |
Pool de connexions |
Le modèle de pool de connexions conserve les ressources sur l'agent de test de charge en répartissant les connexions au serveur Web parmi plusieurs utilisateurs de test de performances de site Web virtuels. Dans le modèle de pool de connexions, la taille du pool de connexions spécifie le nombre maximal de connexions à établir entre l'agent de test de charge et le serveur Web. Si la charge utilisateur est plus grande que la taille du pool de connexions, les tests de performances de site Web exécutés au nom de différents utilisateurs virtuels partagent une connexion. C'est le meilleur modèle à utiliser pour orienter la charge maximum vers la couche Application. Le partage d'une connexion signifie qu'un test de performances de site Web peut devoir attendre avant d'émettre une requête lorsqu'un autre test de performances de site Web utilise la connexion. La durée moyenne pendant laquelle un test de performances de site Web attend avant d'envoyer une requête est suivie par le compteur de performance de test de charge Durée d'attente moyenne d'une connexion. Ce nombre doit être inférieur au temps de réponse moyen d'une page. Si ce n'est pas le cas, la taille du pool de connexions est sans doute trop petite. |
Connexion par itération de test |
La connexion par itération de test ferme la connexion après chaque itération de test et ouvre une nouvelle connexion pour l'itération suivante. Ce paramètre sollicite davantage les ouvertures de session réseau. À moins qu'il s'agisse d'une spécification, il est recommandé d'utiliser l'une des deux options précédentes. |
Taux d'échantillonnage et collecte de données
Choisissez un taux d'échantillonnage approprié selon la longueur de votre test de charge. Un taux d'échantillonnage faible, par exemple cinq secondes, collecte plus de données pour chaque compteur de performance qu'un taux d'échantillonnage élevé. La collecte de grandes quantités de données sur une longue période pourrait provoquer des erreurs d'espace disque. Pour les tests de charge de longue durée, vous pouvez augmenter le taux d'échantillonnage pour réduire la quantité de données que vous collectez. Le nombre de compteurs de performance affecte également la quantité de données collectées. Pour les ordinateurs sous test, la réduction du nombre de compteurs réduit la quantité de données que vous collectez.
Vous devez faire des essais pour déterminer quel taux d'échantillonnage fonctionne le mieux pour votre test de charge. Toutefois, le tableau suivant contient les taux d'échantillonnage recommandés que vous pouvez utiliser pour commencer.
Durée du test de charge |
Taux d'échantillonnage recommandé |
|---|---|
< 1 heure |
5 secondes |
1 à 8 heures |
15 secondes |
8 à 24 heures |
30 secondes |
> 24 heures |
60 secondes |
Temps de réflexion
Le temps de réflexion pour les requêtes de tests de performances de site Web a un effet significatif sur le nombre d'utilisateurs qui peut être pris en charge avec des temps de réponse raisonnables. Le changement des temps de réflexion de 2 secondes à 10 secondes permet généralement de simuler 5 fois plus d'utilisateurs. Toutefois, si votre objectif est de simuler de vrais utilisateurs, vous devez définir le temps de réflexion selon la façon dont vous pensez que les utilisateurs se comporteront sur votre site Web. L'augmentation du temps de réflexion et du nombre d'utilisateurs n'augmentera pas nécessairement la contrainte sur votre serveur Web. Si le site Web est authentifié, le type de schéma utilisé affectera les performances.
Si vous désactivez les temps de réflexion pour un test de performances de site Web, vous pourrez peut-être générer un test de charge dont le débit sera supérieur en termes de requêtes par seconde. Si vous désactivez les temps de réflexion, vous devez également réduire le nombre d'utilisateurs à un nombre beaucoup plus petit que lorsque les temps de réflexion sont activés. Par exemple, si vous désactivez les temps de réflexion et essayez d'exécuter 1000 utilisateurs, il est probable que vous submergiez le serveur cible ou l'agent de test de charge.
Pour plus d'informations, consultez Modification des temps de réflexion pour simuler les retards d'interaction humaine avec un site Web dans les scénarios de tests de charge.
Définition des objectifs de temps de réponse pour des requêtes de tests de performances de site Web
L'une des propriétés d'une requête de test Web est l'objectif de temps de réponse. Si vous définissez des objectifs de temps de réponse pour vos requêtes de tests de performances de site Web, lorsque le test de performances de site Web est exécuté dans un test de charge, l'analyseur de test de charge rapporte le pourcentage de tests de performances de site Web pour lequel le temps de réponse n'a pas atteint l'objectif. Par défaut, aucun objectif de temps de réponse n'est défini pour les requêtes Web.
De plus, si vous utilisez la règle de validation Objectif de temps de réponse, les pages qui ne respectent pas l'objectif de temps de réponse génèrent une erreur dans le test de charge. Si vous utilisez le journal d'erreur, vous pouvez savoir ce que faisait l'utilisateur virtuel lorsque la page lente s'est produite.
Pour plus d'informations, consultez Comment : définir des objectifs de temps de réponse pour une page dans un test des performances de site Web.
Inclusion de détails de minuterie pour collecter des données de centile et activation de la vue Détails
Les paramètres d'exécution incluent une propriété nommée Stockage des détails de minuterie. Si cette propriété est activée, le temps nécessaire à l'exécution de chaque test, transaction et page individuels pendant le test de charge est stocké dans le référentiel des résultats du test de charge. Cela active le graphique d'activités des utilisateurs virtuels dans l'analyseur de test de charge. Cela permet aux 90ème et 95ème et 99ème données de centile et l'écart standard de s'afficher dans l'analyseur de test de charge des tables Tests, Transactions et Pages.
Par défaut, la propriété Stockage des détails de minuterie est activée pour prendre en charge le graphique d'activités des utilisateurs virtuels dans la vue Détails du résultat de test de charge à l'aide de l'analyseur de test de charge.
Pensez à désactiver la propriété Stockage des détails de minuterie pour les tests volumineux. et ce pour deux raisons importantes :
La quantité d'espace requise dans le référentiel des résultats du test de charge pour stocker les détails de minuterie peut être très élevée, en particulier pour les longs tests de charge.
Le temps nécessaire pour stocker ces données dans le référentiel des résultats du test de charge à la fin du test de charge est long parce que ces données sont stockées sur les agents de test de charge jusqu'à ce que l'exécution du test de charge soit terminée.
Si l'espace disque nécessaire est disponible dans le référentiel des résultats du test de charge, vous pouvez activer Stockage des détails de minuterie pour obtenir les données de centile. Vous avez deux possibilités pour activer Stockage des détails de minuterie : StatisticsOnly et AllIndividualDetails. Quelle que soit l'option choisie, tous les tests, pages et transactions individuels sont chronométrés et les données de centile sont calculées à partir des données de temporisation individuelles. Si vous choisissez StatisticsOnly, les données de temporisation individuelles sont supprimées du référentiel après le calcul des données de centile. La suppression des données réduit la quantité d'espace requise dans le référentiel. Toutefois, si vous souhaitez traiter les données de détails de minuterie directement, à l'aide d'outils SQL, ou activez l'affichage des détails du graphique d'activités des utilisateurs virtuels, choisissez AllIndividualDetails afin qu'elles soient enregistrées dans le référentiel.
Pour plus d'informations, consultez Analyse de l'activité des utilisateurs virtuels d'un test de charge dans la vue Détails de l'analyseur de test de charge et Comment : configurer les tests de charge pour collecter les détails complets afin d'activer le graphiques d'activités des utilisateurs virtuels dans les résultats des tests.
Définition de la propriété Pourcentage de nouveaux utilisateurs
Chaque scénario contenu dans un test de charge a une propriété nommée Pourcentage de nouveaux utilisateurs. Cette propriété affecte la façon dont le moteur d'exécution de test de charge simule la mise en cache qui serait exécutée par un navigateur Web. La valeur par défaut du pourcentage de nouveaux utilisateurs est 0. Cela signifie que chaque utilisateur virtuel conserve un cache virtuel des requêtes dépendantes et une liste de cookies entre les itérations de test. Le cache fonctionne comme un cache de navigateur ; les requêtes suivantes d'URL ne seront pas effectuées, ce qui ressemble bien aux véritables navigateurs Web.
Si la propriété Pourcentage de nouveaux utilisateurs a la valeur 100 %, chaque utilisateur est effectivement un « utilisateur ponctuel » et ne retourne jamais sur le site. Dans ce cas, chaque itération de test de performances de site Web exécutée dans un test de charge est traitée comme une nouvelle utilisation du site Web, sans contenu dans le cache du navigateur provenant de visites précédentes sur le site en question. Par conséquent, toutes les requêtes dans le test de performances de site Web, y compris toutes les requêtes dépendantes telles que les images, sont téléchargées.
Notes
Il existe une exception : lorsque la même ressource pouvant être mise en cache est demandée plusieurs fois dans un test de performances de site Web.
Utilisez la valeur par défaut 0 % des nouveaux utilisateurs pour orienter la charge maximum vers la couche Application de votre site Web. Non seulement cela simule de manière fidèle les vrais utilisateurs, mais aussi une charge plus importante est orientée vers la couche Application dans laquelle la plupart des problèmes de performances se produisent. Pour plus d'informations, consultez Comment : spécifier le pourcentage des utilisateurs virtuels qui utilisent les données du cache Web.
Activation du profileur ASP.NET
Une nouvelle fonctionnalité dans Microsoft Visual Studio 2010 est l'adaptateur de données de diagnostic de profileur ASP.NET qui vous permet de collecter les données du profileur ASP.NET de la couche Application pendant l'exécution d'un test de charge. Vous ne devez pas exécuter le profileur pour les longs tests de charge, par exemple les tests de charge qui s'exécutent pendant plus d'une heure, car le fichier du profileur peut devenir volumineux (quelques centaines de mégaoctets). Exécutez de préférence des tests de charge plus courts avec le profileur ASP.NET, qui présente l'avantage d'un outil de diagnostic approfondi des problèmes de performances.
Pour plus d'informations, consultez Comment : configurer le profileur ASP.NET pour les tests de charge à l'aide de paramètres de test.
Activation de l'enregistrement d'utilisateur virtuel
Une nouvelle fonctionnalité dans Microsoft Visual Studio 2010 vous permet de collecter des journaux complets sur les tests qui ont échoué ou de spécifier une fréquence d'enregistrement des tests. L'enregistrement est contrôlé par les propriétés Enregistrer le journal lors de l'échec d'un test, Enregistrer la fréquence d'entrée au journal pour les tests terminés et Nombre maximal de journaux des tests. Le nombre de journaux collecté est contrôlé par les paramètres des propriétés Nombre maximal de journaux des tests et Enregistrer la fréquence d'entrée au journal pour les tests terminés. Les paramètres par défaut empêchent la collecte d'un grand nombre de journaux. Pour les tests de longue durée qui génèrent des millions de requêtes, n'utilisez pas le paramètre Enregistrer la fréquence d'entrée au journal pour les tests terminés, sinon le nombre de journaux sera trop élevé. En outre, conservez le paramètre de la propriété Nombre maximal de journaux des tests (qui contrôle le nombre maximum de journaux par type d'erreur) sur une valeur raisonnable. Vous devez conserver ces paramètres pour empêcher la collecte de dizaines de milliers de journaux, car cela augmente à la fin du test la durée de collecte des journaux et occupe de l'espace de stockage dans la base de données du test de charge.
Pour plus d'informations, consultez Modification des paramètres d'enregistrement du test de charge.
Activation du traçage SQL
Les paramètres d'exécution incluent une propriété nommée Traçage SQL activé. Cette propriété vous permet d'activer la fonctionnalité de traçage de Microsoft SQL Server pour la durée d'un test de charge. Cela constitue une alternative au démarrage d'une session SQL Profiler distincte pendant que le test de charge s'exécute pour diagnostiquer des problèmes de performance SQL. Si la propriété est activée, les données de trace SQL s'affichent dans l'analyseur de test de charge. Vous pouvez les consulter à la page Tables dans la table Trace SQL.
Pour activer cette fonctionnalité, l'utilisateur qui exécute le test de charge doit avoir les privilèges SQL requis pour exécuter le traçage SQL. Lorsqu'un test de charge s'exécute sur un ordinateur distant, à l'aide d'un agent de test et d'un contrôleur de test, l'utilisateur du contrôleur doit avoir les privilèges SQL. Vous devez également spécifier un répertoire, généralement un partage réseau, où le fichier des données de trace sera enregistré. À la fin du test de charge, le fichier des données de trace est importé dans le référentiel de test de charge et associé au test de charge afin qu'il puisse être affiché ultérieurement à l'aide de l'analyseur de test de charge.
Pour plus d'informations, consultez Configuration des paramètres d'exécution des tests de charge et Comment : intégrer des données de trace SQL à l'aide de l'éditeur de test de charge.
Gestion d'un nombre approprié d'ordinateurs agents
Si l'utilisation de l'UC d'un ordinateur agent est supérieure à 75 % ou si sa mémoire physique disponible est inférieure à 10 %, l'ordinateur est surchargé. Ajoutez des agents à votre contrôleur de test pour garantir que l'ordinateur agent ne se transforme pas en goulot d'étranglement dans votre test de charge.
Pour plus d'informations, consultez Distribution des tests de charge entre plusieurs machines de test à l'aide des contrôleurs de test et des agents de test et Comment : spécifier les agents de test à utiliser dans les scénarios de test de charge.
Voir aussi
Tâches
Concepts
Analyse des erreurs dans les tests de charge à l'aide de la table d'erreurs
Autres ressources
Création et modification de tests de charge
Consideration for Load Tests that Contain Web Performance Tests