Mike Schelstrate

Mars 2000

Résumé

Cet article traite de l'importance des tests de stress des composants Data Access dans les applications DNA de Microsoft Windows ainsi que des moyens permettant de faciliter le processus.

Sommaire

• Introduction
• Pourquoi soumettre mon application à des tests de stress ?
• Préparation de l'exécution d'un test de stress
• Exécution du test de stress
• Évaluation des résultats d'un test de stress
• Conseils pour réussir un test de stress
• Synthèse finale

Introduction

Le processus de développement et le déploiement d'une application DNA Microsoft Windows comprend une étape souvent négligée : soumettre l'application à un test de stress afin de garantir qu'elle se comportera comme prévu lorsqu'elle sera utilisée dans le monde de la production et qu'un grand nombre d'utilisateurs autorisés y accéderont. Cet article souligne l'importance des tests de stress dans le développement des applications utilisant les composants Microsoft Data Access (MDAC) et donne quelques conseils qui aideront à réaliser ce processus.

L'objectif de cet article est d'aider les développeurs expérimentés et les professionnels de l'informatique à concevoir et à implémenter un scénario de tests de stress complet, à analyser les résultats des tests et à recommander les modifications qui permettront de corriger les défaillances. Le lecteur doit être familiarisé avec les technologies suivantes : Microsoft Windows NT Server, Microsoft SQL Server, Microsoft Internet Information Server (IIS), Active Server Pages (ASP), Microsoft ActiveX Data Objects (ADO) et l'environnement des services de composants Microsoft (ou Microsoft Transaction Server [MTS] si vous utilisez Windows NT).

Il convient d'insister sur l'importance d'une bonne implémentation de la logique métier et des procédures d'accès aux données dans les composants COM ou DCOM, y compris les composants ADO. Pour des raisons de performance et de fiabilité, ces procédures ne doivent pas résider dans les pages ASP. Si vous considérez que la performance de votre application en situation de stress est un élément important, vous aurez probablement conçu votre application de façon à ce qu'elle utilise ces composants et tire tous les avantages de l'environnement des services de composants.

Cet article ne cherche pas à débattre des problèmes de stress posés par le navigateur client ou par les problèmes liés à la largeur de la bande passante mais s'intéresse avant tout aux composants d'accès aux données côté serveur et à leur interaction avec Internet Information Server. Ce document n'aborde pas non plus les enjeux que représente l'utilisation des services RDS (Remote Data Services).

Pourquoi soumettre mon application à des tests de stress ?

Les tests de stress devraient toujours être réalisés avant que l'application ne soit déployée dans un environnement de production. L'objectif principal des tests de stress sur les applications conçues pour le Web est d'accomplir les tâches suivantes :

• Mesurer de façon précise les répercussions pour l'utilisateur individuel d'une augmentation de la charge d'utilisation supportée par le système
• Déterminer la capacité maximale du matériel utilisé par l'application pour savoir si une mise à niveau du matériel est nécessaire avant de déployer l'application dans un environnement de production
• Définir le seuil de performances acceptable en termes de temps de réponse moyen par page pour l'utilisateur de l'application
• Garantir que le seuil de performances reste à un niveau acceptable lorsque le système est utilisé par le nombre maximal d'utilisateurs concomitants estimé

Pour la plupart des applications Web, la satisfaction de l'utilisateur est le principal facteur de succès d'une application. Toutefois de nombreuses raisons justifient de soumettre votre application à un test de stress, notamment :

• Les applications qui fonctionnent bien pendant la phase de développement peuvent rencontrer des problèmes d'exécution lorsqu'elles sont utilisées dans un environnement soumis à un stress élevé. Par exemple, lorsque des machines Internet Information Server ou SQL Server sont utilisées simultanément par plusieurs applications, l'ajout de votre nouvelle application peut interférer avec les applications existantes ou même les interrompre si votre application n'est pas conçue pour fonctionner correctement dans cette situation.
• L'impression que votre application laisse à vos clients lors des premières utilisations est capitale. Si elle est défavorable en raison de problèmes de stress, il sera très difficile de leur faire changer d'avis même si vous parvenez à résoudre les problèmes. En revanche, en soumettant vos applications à des tests de stress appropriés avant leur déploiement, vous vous forgerez la réputation d'un développeur qui crée des applications performantes, rapides et qui fonctionnent comme prévu.
• L'équipe informatique responsable du déploiement et de la maintenance de votre application appréciera les tests de stress que vous aurez réalisés au moins autant, sinon plus, que vos clients. Ils sont en première ligne et c'est à eux que seront communiquées en premier lieu les opinions et les remarques. Si vous pouvez anticiper de façon fiable les problèmes d'évolutivité auxquels sera confrontée l'équipe informatique, les membres de cette équipe seront davantage prêts à vous prêter main forte si leur aide vous est nécessaire.
• Les éventuels partenaires commerciaux doivent également être pris en compte dans la grille de satisfaction des consommateurs. Ils peuvent représenter un atout important dans le succès de votre application s'ils décident de l'inclure dans un lot d'applications plus important.

Préparation de l'exécution d'un test de stress

Pour déterminer les valeurs optimales d'analyse du serveur, ou valeurs de référence, il faut avant tout tester la configuration d'un système pilote dans un environnement contrôlé. Ensuite, vous devez effectuer le test dans un environnement de production simulé pour déterminer comment la configuration de l'environnement de production affecte les résultats du système pilote.

Lorsque vous préparez la phase de tests de stress de votre cycle de développement, vous devez vous intéresser aux points suivants :

• Configuration matérielle et logicielle
• Configuration serveur
• Configuration de sécurité
• Configuration de la charge d'utilisation
• Sélection des bons outils de stress

Configuration matérielle et logicielle

Le système pilote doit imiter autant que possible le système de production. Les configurations matérielles de l'unité centrale, de la RAM et de la bande passante du réseau sont les domaines les plus importants à soumettre à des tests de stress. Il faut à tout prix dupliquer les configurations logicielles, comme la version et le Service Pack Microsoft Windows appropriés, la version des composants MDAC, la configuration de Internet Information Server et toute autre application qui fonctionnera sur la même machine dans le système de production réel. Installez et enregistrez vos règles métiers et vos composants COM d'accès aux données de niveau intermédiaire et configurez-les en fonction des besoins de votre application.

Assurez-vous de configurer votre site Web de test de façon à permettre une exécution in-process ou out-of-process selon la configuration finale requise. Cette option vous permet de déterminer si votre application Web s'exécutera dans le même espace d'adressage que IIS ou dans un espace d'adressage qui lui est propre. Cette configuration aura un impact majeur sur les tests de stress qui seront réalisés. Les illustrations suivantes montrent les configurations de la page de propriétés Propriétés de stress pour une application out-of-process dans Microsoft Windows NT 4.0 et dans Microsoft Windows 2000. Dans Windows NT 4.0, cochez la case Exécuter dans un espace mémoire séparé (processus isolé) pour exécuter l'application Web en mode out-of-process. Dans Windows 2000, définissez Protection d'application sur Moyenne ou sur Élevée pour exécuter l'application Web en mode out-of-process.

Configuration serveur

Configurez Internet Information Server de façon à imiter le serveur du système de production. La page de propriétés Gestionnaire des services Internet fournit plusieurs options de réglage pour IIS. Il est particulièrement important de déterminer s'il faut activer l'enregistrement dans le journal (ce qui peut considérablement ralentir le système) et de sélectionner, sous l'onglet Performance, le nombre d'accès escomptés par jour.

C'est au niveau du serveur de données que la majorité des problèmes de stress peuvent être résolus. Pour obtenir une exécution efficace des requêtes, il est indispensable de normaliser de façon adéquate la conception de la base de données. Par conséquent, il faut absolument que vous réalisiez les tests de stress en utilisant la même conception de base de données que celle avec laquelle votre application est sensée fonctionner. En outre, vous devez garantir que les tables sont peuplées avec la quantité maximale de données que votre application pourra générer. De plus, assurez-vous que les options de configuration du serveur de données pour le test (surtout les niveaux de verrouillage et d'isolation et les techniques d'optimisation employées, comme l'indexation des tables) correspondent aux options de configuration du serveur de données du système de production.

Configuration de sécurité

Le système de sécurité de votre application peut avoir un impact considérable sur la performance de votre application en situation de stress élevé, surtout si ce système utilise une technologie de cryptage comme l'API de cryptographie de Microsoft. Par conséquent, vous devez configurer votre batterie de tests de façon à ce qu'elle utilise le même système de sécurité, mais pas nécessairement les mêmes autorisations. Le système d'autentification pass-through NT LAN Manager (NTLM) de Microsoft Windows est probablement le protocole de sécurité le plus utilisé pour les applications intranet qui accèdent aux enregistrement de données principaux. Si possible, vous devez envisager l'utilisation des rôles à partir des services de composants (ou MTS, dans Windows NT) pour simplifier et rationaliser le processus d'authentification de sécurité et améliorer la performance et la stabilité.

Configuration de la charge d'utilisation

Vous devez commencer par déterminer le nombre maximal d'utilisateurs qui accéderont, selon vous, à votre application, puis multiplier ce nombre par deux ; une application réussie a toutes les chances d'être utilisées par bien plus d'utilisateurs que prévu. Ensuite, calculez l'heure de la journée à laquelle la majorité des utilisateurs souhaiterons accéder à l'application et déterminez la charge que devra supporter le réseau à cette heure-là, moment auquel vous devez tester votre application. Cette stratégie vous permet de tester l'impact de la charge d'utilisation ainsi que la configuration matérielle à l'échelle du système afin de garantir que votre application réagira comme prévu aux heures de pointe du réseau.

Sélection des bons outils de stress

Dans les centres de données réels, les serveurs Web sont confrontés à des niveaux de connection élevés. En effet, les clients sont nombreux à se connecter aux applications Web, que ce soit via le réseau intranet de leur entreprise ou avec Internet. Les outils de stress Web doivent permettre de simuler un grand nombre de connections simultanées avec suffisamment de threads pour optimiser les connections concomitantes tout en limitant la taille des paquets envoyés vers le serveur Web. Heureusement, il existe de nombreux outils conçus pour simuler parfaitement ces conditions. L'un de ces outils, Web Application Stress Tool de Microsoft, est actuellement proposé gratuitement par Microsoft à l'adresse suivante : http://webtool.rte.microsoft.com/default.htm (en anglais). Il fournit toutes les capacités nécessaires ainsi que des fonctionnalités supplémentaires utiles comme l'émission de rapports détaillés.

L'outil Web Application Stress

L'outil Web Application Stress active l'environnement de test en simulant de façon réaliste la situation dans laquelle de nombreux navigateurs envoient des requêtes pour accéder aux pages d'une application Web. Il vous permet en outre d'enregistrer un script en accédant, à partir de votre navigateur, aux pages que vous souhaitez inclure dans le test. Ce script peut alors être enregistré et exécuté à partir de n'importe quel client Windows NT ou Windows 2000 disposant de l'application. Il n'est pas nécessaire d'installer autant de clients que pour l'application destinée à la production car l'outil Web Application Stress est capable de simuler plusieurs clients à partir d'une seule station de travail.

Remarque   Lorsque vous exécutez votre test de stress, veillez à ne pas accroître le niveau de stress sur les clients afin d'éviter que les machines utilisées pour le test ne passent plus de temps à gérer les changements de contexte entre les threads qu'à effectuer les tâches requises. Pour garantir que les threads sont bien distribuées sur les clients, utilisez plusieurs clients lorsque vous testez une application Web, de façon à éviter les limitations de ressources qu'impose l'utilisation d'une seule machine cliente.

Analyseur de performances

Pour soumettre vos composants d'accès aux données à des tests de stress efficaces et faire une bonne interprétation des résultats, l'utilisation d'une méthode d'analyse et d'enregistrement des statistiques de fonctionnement est indispensable. L'Analyseur de performances, fourni avec Microsoft Windows NT et Microsoft Windows 2000, est le meilleur outil disponible d'analyse et d'enregistrement de ces statistiques, à la fois dans Internet Information Server et sur votre serveur de données.

Autres outils

En plus de l'utilisation de l'Analyseur de performances sur Internet Information Server, il est nécessaire d'analyser certains compteurs personnalisés sur le serveur de données. La plupart des applications de serveur de données hautement performantes, comme Microsoft SQL Server, Oracle et Microsoft Exchange Server, incluent des compteurs d'analyse de performances personnalisés qui peuvent être utilisés pour évaluer le bon fonctionnement d'une application et du matériel sur lequel elle est utilisée.

Exécution du test de stress

Une fois que vous avez soigneusement planifié votre stratégie de test, l'exécution des tests est plutôt facile. Dans un test de performance, la première tâche consiste à utiliser un outil, comme le Web Application Stress Tool de Microsoft, pour soumettre le site Web à cette contrainte et mesurer le nombre de requêtes maximal que le serveur Web peut gérer en une seconde. Il s'agit là d'une mesure quantitative. La deuxième tâche consiste à déterminer quelles sont les ressources qui limitent le nombre de requêtes par seconde (unité centrale, mémoire ou dépendances principales) ; cette analyse relève plus de l'intuition que d'une technique de mesure à proprement parler.

Vous devez tout d'abord sélectionner les pages ASP que vous souhaitez exécuter. (Recherchez les pages les plus lentes du site Web et utilisez-les). Pour choisir les pages, vous devez vous demander quelles sont celles qui accèdent le plus souvent à la base de données et qui comportent les requêtes les plus volumineuses ou les plus complexes. Cette sélection est très importante : il vaut mieux inclure plus de pages que nécessaire que d'ignorer des chemins essentiels d'accès au code. De même, vous devez le cas échéant envisager de faire accéder votre application de test à une série de pages dans un ordre donné, de transmettre des cookies ou des chaînes de requêtes avec chaque page, tout comme le ferait l'application en situation réelle.

Remarque   En fonction de l'application, il peut être nécessaire de préparer les pages ASP avant le test. Pour certaines de vos pages, vous devrez pré-programmer les valeurs de paramètres habituellement générées par l'application et que l'outil de stress Web est incapable de produire de façon dynamique.

Lorsque vous exécutez votre application dans Internet Information Server, vous devez analyser (grâce à l'Analyseur de performances) les compteurs suivants :

• Pages ASP : requêtes par seconde, requêtes rejetées, longueur totale de la file d'attente et nombre de sessions en cours
• Processus Inetinfo : octets privés, octets virtuels et nombre de handles ouverts
• Processeur : pourcentage de temps utilisateur contre pourcentage de temps privilégié

Remarque   Si votre application fonctionne dans son propre espace de mémoire sur Windows NT 4.0 (ou avec la page Stress Properties définie sur Protection d'application : Élevée [Isolée] dans Windows 2000), vous devez analyser mtx.exe (ou le processus dllhost dans Windows 2000) plutôt que le processus Inetinfo.

Comme le montre l'illustration suivante, le compteur du nombre de requêtes par seconde des pages ASP dans l'analyseur de performances affichera le débit réel de votre application (1 000 requêtes/seconde dans cet exemple). Ces données statistiques vous permettront d'analyser la performance de Internet Information Server en situation de stress et de repérer les éventuels goulets d'étranglement. Vous pourrez ainsi évaluer la capacité de votre application à servir un nombre maximal d'utilisateurs dans un temps de réponse acceptable.

Un serveur Web utilisant la technologie ASP attribue à chaque requête de page une thread issue d'une réserve définie au démarrage ; si toutes les threads sont utilisées, les requêtes de page suivantes sont placées dans une file d'attente. En mesurant la longueur totale de la file d'attente avec l'Analyseur de performances, vous pouvez déterminer le nombre de clients en attente d'une réponse du serveur.

Les blocages et les verrouillages d'accès concurrentiels sont deux des problèmes de base de données les plus courants liés au stress et qui ne soient pas d'origine matérielle. Sur le serveur de données, vous devrez utiliser les résultats des compteurs personnalisés de l'Analyseur de performances fournis par les stocks de données pour analyser au minimum les points suivants :

• Requêtes de verrouillage
• Blocages par seconde
• Augmentations de verrous de tables par seconde
• connections utilisateur
• Transactions actives

Votre application Web doit aussi être configurée pour utiliser la concentration des ressources OLE DB, qui est gérée automatiquement par le fournisseur OLE DB de niveau intermédiaire pour Microsoft SQL Server 7.0. En créant les objets de connection pour chaque page et en les libérant immédiatement, la base de données peut gérer des milliers d'utilisateurs concomitants avec beaucoup moins de connections ouvertes à la base de données. Cela permet de conserver les ressources de la base de données et d'accroître l'évolutivité. Cette amélioration de la performance peut être analysée en suivant l'évolution du nombre de connections utilisateur (grâce à l'analyseur de performances) sur le serveur de données. Avec l'augmentation du débit, le nombre de connections utilisateur doit rester stable tandis que la concentration limite le nombre de connections réellement créées sur le serveur de données.

Le processus de réglage d'une application par rapport à la base de données est essentiel à la réussite des objectifs de performance et doit être intégré au cycle de développement. Il consiste notamment à optimiser la taille de la mémoire allouée, à distribuer l'application sur les lecteurs et les contrôleurs et à localiser les composants ActiveX sur les machines. Efforcez-vous si possible d'éliminer le tri des données entre les processus, cette opération étant très coûteuse.

Exécutez le test de stress sur une durée supérieure de 50 % à la durée d'utilisation sans interruption prévue pour l'application en situation réelle. De nombreux problèmes, notamment des fuites de mémoire, ne se manifestent qu'après une utilisation prolongée de l'application.

Ce qu'il faut rechercher lors du test de stress

La valeur moyenne de chaque compteur de l'Analyseur de performances est déterminée par la configuration spécifique de votre application et de votre matériel. Par conséquent, lorsque vous exécutez des tests de stress, vous devez vérifier chaque compteur et guetter tout écart par rapport à ces valeurs moyennes.

Analyse de Internet Information Server

Lorsque vous recherchez les goulets d'étranglement, les domaines les plus importants à analyser sur la machine Internet Information Server sont les suivants :

• Utilisation de l'unité centrale
• Utilisation de la mémoire
• Débit

En fonction de l'environnement d'application prévu, vous pouvez également souhaiter analyser d'autres domaines de performance lors des tests de stress. Chacun des scénarios suivants peut indiquer un problème dans votre application qui pourrait être résolu avant la version finale.

Utilisation de l'unité centrale

La diminution de l'utilisation de l'unité centrale peut indiquer une diminution de la performance de l'application, probablement un problème de contention de threads.

Lorsque vous analysez la proportion du temps UC utilisée par le temps utilisateur d'une part et le temps du noyau d'autre part, rappelez-vous que le temps utilisateur doit, en règle générale, représenter 80 à 90 % du temps UC total. Par conséquent, si le temps mode noyau dépasse 20 %, cela indique une contention des appels API au niveau du noyau.

Pour que vos machines soient rentables, vous devez enregistrer un taux d'utilisation des processeurs supérieur à 50 % lors des pics de connection. Une valeur d'utilisation inférieure peut révéler l'existence d'autres goulets d'étranglement dans votre système. Il vous faudra les résoudre.

Utilisation de la mémoire

L'augmentation soudaine ou progressive de l'utilisation de la mémoire est un autre type de problème couramment observé lors de l'utilisation prolongée des applications serveur. Lorsque cela se produit, des fuites de mémoire et de ressources sont généralement détectées pendant la phase de test.

Débit

L'analyse du compteur du nombre de requêtes par seconde des pages ASP vous permet de savoir si et quand votre application commence à rencontrer des problèmes de performance. En situation réelle, ce compteur varie généralement mais en définissant avec soin le nombre de threads et de connections concomitantes (par exemple, à partir de l'écran de configuration de l'outil Web Application Stress), vous serez capable de simuler un nombre de requête constant. Une chute soudaine de ce compteur indique un problème.

Tests optionnels

Les exemples suivants montrent d'autres types d'analyses que vous pouvez souhaiter réaliser lors des tests de stress :

• Longueur totale de la file d'attente.   Généralement, le compteur Total Queue Length de l'analyseur de performances varie constamment. Par conséquent, si la longueur totale de la file d'attente n'augmente jamais alors que le taux d'utilisation des processeurs est peu élevé, cela peut indiquer que le site fonctionne trop facilement et qu'il dispose d'une capacité excessive pour cette charge de stress. Si la longueur de votre file d'attente fluctue mais que vos processeurs fonctionnent en dessous de 50 %, cela peut indiquer que certaines de vos requêtes bloquent et nécessitent d'être optimisées.
• Temps de réponse du navigateur.   Vous pouvez accéder régulièrement à vos pages ASP à partir d'un navigateur pour analyser le temps de réponse et garantir que le test de stress fonctionne bien et que le site Web est toujours capable de servir correctement les pages ASP. Nous vous recommandons de réaliser ces analyses au moins deux fois par jour pendant toute la durée des tests.
• Erreurs de temporisation.   Pendant les tests du navigateur, restez attentif aux erreurs de temporisation qui sont renvoyées par Internet Information Server ; ces erreurs peuvent indiquer qu'un trop grand nombre d'utilisateurs cherchent à accéder à l'application simultanément.

Analyse du serveur de données

Le traitement interne, par le serveur de données, des différents services MDAC et le formatage des données à afficher consomment généralement la majorité des ressources serveur destinées à l'application Web. Par conséquent, lorsque vous soumettez l'application à des tests de stress, vous devez absolument vous pencher sur la performance de ces composants puisqu'elle est liée à l'accès aux données et à la manipulation de ces données dans l'application.

Les connections utilisateur à la base de données, les contentions de verrouillage et les blocages sont les premiers éléments à analyser sur le serveur de données. Consultez périodiquement les informations de processus dans la console de management de votre base de données (par exemple, sur une machine utilisant SQL Server, dans la zone Activité en cours de SQL Enterprise Manager). Recherchez les ID bloquant le processus serveur, cause courante d'une absence de réponse aux requêtes de données. Il s'agit d'un problème de contention qui requiert généralement des modifications importantes dans la conception de la base de données ou dans la logique de l'application.

Les blocages peuvent être repérés de diverses manières. La méthode la plus courante pour les identifier consiste à utiliser le compteur personnalisé Nombre d'interblocages/seconde de l'Analyseur de performances. Votre application doit déjà pouvoir rechercher les problèmes de blocage et y répondre de façon appropriée parce que si on laisse le serveur de données désigner la victime du blocage (c'est à dire l'utilisateur ou la session qui sera annulée pour résoudre ce blocage), cela peut engendrer des problèmes pour votre application. L'application doit détecter l'état de blocage dès son apparition et réagir en conséquence. La réponse fréquente à ce type de problème consiste à attendre quelques millisecondes et à tenter à nouveau l'opération ; en principe, les blocages sont des erreurs sensibles au temps qui disparaissent lorsque l'opération est réitérée.

Évaluation des résultats d'un test de stress

Lorsque les tests de stress sont terminés et que les résultats sont disponibles pour vérification, la comparaison entre les références de performance cible et les données statistiques collectées pendant les tests indiquera les modifications nécessaires pour garantir un débit conforme aux attentes des utilisateurs. Vous trouverez ci-dessous les domaines spécifiques qu'il vous faudra passer en revue et évaluer en vue de corriger comme il se doit les problèmes de performance :

• Matériel
• Conception de la base de données
• Composants ActiveX
• Curseurs client
• Exécution ASP
• Charge de Internet Information Server

Matériel

La mise à niveau du matériel est probablement la solution la plus facile et la moins coûteuse pour accroître le débit de votre application. Normalement, il est beaucoup plus rentable de mettre à niveau votre matériel que de payer une équipe de développeurs pour réécrire certaines parties de l'application. Par exemple, en ajoutant simplement de la RAM à votre serveur, vous pouvez doubler le débit de votre application. Toutefois, si les résultats des tests indiquent que l'origine du goulet d'étranglement est l'utilisation de l'UC, la mise à niveau peut s'avérer plus coûteuse car il faudra probablement mettre à niveau toute la machine et accroître le nombre d'unités centrales et leur vitesse.

Il existe d'autres moyens d'améliorer le matériel : accroître la vitesse de vos disques durs et de vos contrôleurs, mettre des cartes d'interface réseau plus rapides ou en accroître le nombre.

Conception de la base de données

Lorsque vous abordez les problèmes relatifs à la conception de la base de données, recherchez les points névralgiques. Analysez les statistiques de blocage et vérifiez que votre application est optimisée pour éviter les blocages autant que possible. Envisagez si nécessaire de modifier les algorithmes d'accès aux données afin d'éviter la contention. Essayez différentes solutions d'indexation. Étudiez le plan d'exécution des requêtes de votre serveur de données pour vérifier que vos requêtes utilisent les bons index, et ainsi de suite.

Composants ActiveX

Les composants ActiveX, qui incluent des références à la bibliothèque de types des objets de données ActiveX, doivent faire l'objet d'une analyse attentive en vue d'une optimisation. N'utilisez pas les propriétés par défaut autorisées dans ADO. Pour éviter d'utiliser accidentellement une propriété par défaut, définissez toujours les propriétés (Cursor Type ou Cursor Location, par exemple).

Curseurs client

Si votre application Web consomme une quantité de mémoire anormalement élevée, l'origine du problème peut être une mauvaise utilisation des emplacements des curseurs. Lorsque vous utilisez des curseurs client (recordset.cursorlocation = adUseClient), pensez que le client est en fait Internet Information Server et non le navigateur. (Il existe une exception à cette règle lorsque vous utilisez Remote Data Services, mais elle n'est pas présentée dans cet article). Le fait de penser que le curseur client déplace l'ensemble du jeu d'enregistrements vers le navigateur plutôt que vers une machine utilisant IIS est une erreur fréquemment commise par les développeurs. Par conséquent, rappelez-vous que vous enregistrez en fait le jeu d'enregistrements sur une machine utilisant IIS. Cela vous permettra de mieux évaluer la quantité de ressources utilisées.

Par exemple, si votre application doit accéder à une table où figurent un état valide ou des codes départementaux et que ces informations sont enregistrées dans un serveur de données, il est beaucoup plus efficace d'utiliser un curseur client pour créer un jeu d'enregistrements qui réside sur la machine IIS et d'accéder ensuite localement aux codes en évitant ainsi les aller-retours inutiles vers le serveur de données chaque fois que l'application accède à ces données. Assurez-vous simplement que vous tenez bien compte des échanges et ne surchargez pas la mémoire de l'IIS si la mémoire disponible est insuffisante.

Exécution ASP

Si vos pages ASP qui contiennent les procédures d'accès aux données sont trop longues à exécuter, il peut s'avérer nécessaire de déplacer le code d'accès aux données depuis les pages ASP vers les composants ActiveX, placés de préférence dans des lots au sein de Microsoft Transaction Server (dans Windows NT) ou des services de composants (dans Windows 2000), en fonction du système d'exploitation que vous utilisez. Ce code compilé fonctionne de façon beaucoup plus efficace que le code crypté et interprété contenu dans les pages ASP.

Charge de Internet Information Server

Analysez le nombre et les types d'applications utilisant Internet Information Server. Vous devrez peut-être ajouter d'autres serveurs, déplacer l'application vers un autre serveur ou envisager d'implémenter le Service Équilibrage de charge de Windows.

Conseils pour réussir un test de stress

• À faire :
  • Placez toute votre logique métier dans des composants ActiveX et utilisez les pages ASP comme une colle permettant de maintenir le tout. Encapsulez le code réutilisable dans des bibliothèques.
  • Utilisez MTS (utilisateurs de Windows NT). Cet outil performant permet de concentrer davantage les threads et les ressources pour les objets COM côté serveur et de gérer plus facilement les objets. De plus, MTS offre des capacités transactionnelles.
  • Utilisez la concentration des ressources et des connections. Cette fonctionnalité MDAC est activée par défaut mais on doit la contrôler pour garantir son bon fonctionnement.
  • Réglez votre stock de données. Utilisez si possible des procédures stockées.
  • Pour réduire au maximum le nombre d'opérations d'accès aux données, utilisez la mise en cache pour les entrées, les sorties et les données transformées.
  • Utilisez des applications in-process et des composants ActiveX dès que vous en avez l'occasion.
  • Assurez-vous que le débogage est désactivé dans un environnement de production. Le débogage d'une application force l'affinité des threads.
  • Dans un environnement intranet, confiez certaines tâches au navigateur client lorsque cela est possible.
  • Passez à Windows 2000. Les améliorations de performance et d'évolutivité proposées dans cette nouvelle version sont évidentes lorsque vous devez soumettre une application à un test de stress.
  • Si vous ne pouvez pas encore passer à Windows 2000, il est conseillé d'adopter au moins Microsoft Visual Basic Scripting Edition (VBScript) 5.0. Les performances et la fonctionnalité ont été considérablement améliorées dans cette nouvelle version.
  • Envisagez d'utiliser Microsoft Message Queue Server (MSMQ). Une bonne utilisation de la messagerie asynchrone améliorera de façon considérable les temps de réponse perçus par les utilisateurs.
• À éviter :
  • Utiliser des objets d'application ou de session dans les pages ASP.
  • Placer votre code d'accès aux données dans les pages ASP. Utiliser le code de script pour communiquer avec les fonctions d'accès aux données et les règles métier contenues dans les composants ActiveX.
  • Utiliser le protocole HTTPS/protocole de communication sécurisée SSL, sauf en cas d'absolue nécessité. Ce protocole d'authentification est très coûteux à implémenter.
  • Utiliser l'état de l'application ou l'état de la session alors que cela n'est pas nécessaire.

Synthèse finale

Grâce à Internet, vos applications peuvent accéder à un nombre d'utilisateurs bien plus élevé que les applications client-server traditionnelles. Aujourd'hui, les organisations sont de plus en plus nombreuses à considérer le Web comme faisant partie intégrante de leur stratégie d'entreprise. Elles doivent donc être sûres que la technologie qu'elles utilisent est capable de satisfaire leurs exigences. Les organisations ont besoin non seulement d'outils faciles à utiliser, mais aussi d'une infrastructure capable de gérer leurs besoins en termes de charge d'utilisation. Il est par conséquent plus important que jamais de considérer les tests de stress comme une partie fondamentale de votre politique de tests, surtout si vous incorporez MDAC dans votre application.

Remarque   Pour pouvoir fonctionner correctement en situation de stress, il faut avant tout s'intéresser aux meilleures pratiques dans le cycle de développement. Cela signifie qu'il faut prévoir dès la phase de développement le temps nécessaire pour réaliser des tests de performances en situation de charge et corriger les applications en vue de satisfaire les objectifs de performance.

Les avantages des tests de stress et des réglages répétés de votre application en situation de charge sont évidents :

• Vous obtenez les informations dont vous avez besoin pour garantir le meilleur débit possible pour votre application.
• Vous pouvez évaluer avec précision les caractéristiques d'évolutivité de votre application que vous pourrez ainsi ajuster de façon à atteindre vos objectifs de performance.
• Vous pouvez identifier tôt dans le processus les problèmes de conception susceptibles de dégrader la performance et le débit et réaliser les modifications qui s'imposent avant le déploiement de l'application dans un environnement de production.
• Vos applications se forgeront, auprès de vos clients et de vos partenaires commerciaux, la réputation de programmes à la fois fiables et très performants.

Dernière mise à jour le mardi 6 juin 2000