Test de performances pour SharePoint Server 2010

  • Article

 

S’applique à : SharePoint Server 2010

Dernière rubrique modifiée : 2016-11-30

Cet article explique comment tester les performances de Microsoft SharePoint Server 2010. La phase de test et d’optimisation est une partie essentielle de la gestion de la capacité. Vous devez tester les nouvelles architectures avant de les déployer vers l’environnement de production et vous devez effectuer les tests d’acceptation tout en adoptant les meilleures pratiques de surveillance suivantes afin que les architectures que vous concevez atteignent les objectifs de performances et de capacité. Cela permet d’identifier et d’optimiser les goulots d’étranglement potentiels avant qu’ils n’affectent les utilisateurs dans un déploiement réel. Si vous effectuez une mise à niveau depuis un environnement Microsoft Office SharePoint Server 2007 et que vous envisagez d’apporter des modifications architecturales, ou que vous estimez la charge utilisateur des nouvelles fonctionnalités de SharePoint Server 2010, il est particulièrement important que vous effectuiez les tests afin de vous assurer que votre nouvel environnement SharePoint Server 2010 répond aux objectifs de performances et de capacité.

Une fois que vous avez testé votre environnement, vous pouvez analyser les résultats des tests pour déterminer quelles modifications doivent être apportées afin d’atteindre les objectifs de performances et de capacité définis dans la section Étape 1 : modèle de l’article Planification de la capacité pour SharePoint Server 2010.

Voici les sous-étapes qu’il est recommandé de suivre pour l’environnement de préproduction :

  • Créez l’environnement de test qui imite l’architecture de départ conçue dans la section Étape 2 : conception.

  • Remplissez le stockage avec le jeu de données ou une partie du jeu de données que vous avez identifié dans la section Étape 1 : modèle.

  • Sollicitez le système avec une charge de synthèse qui représente la charge de travail que vous avez identifiée dans la section Étape 1 : modèle.

  • Exécutez les tests, analysez les résultats et optimisez votre architecture.

  • Déployez votre architecture optimisée dans votre centre de données et déployez un projet pilote avec un plus petit ensemble d’utilisateurs.

  • Analysez les résultats du pilote, identifiez les goulots d’étranglement potentiels et optimisez l’architecture. Renouvelez le test si nécessaire.

  • Déployez vers l’environnement de production.

Avant de lire cet article, vous devez lire l’article Vue d’ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2010.

Dans cet article :

  • Créer un plan de test

  • Créer l’environnement de test

  • Créer des tests et des outils

Créer un plan de test

Vérifiez que votre plan satisfait les points suivants :

  • La configuration matérielle est conçue de manière à atteindre les objectifs de performance de production attendus. Mesurez toujours les performances des systèmes de test de manière à obtenir une estimation minimale.

  • Si vous utilisez un code personnalisé ou un composant personnalisé, il est important de tester les performances de ces composants de manière isolée pour valider leurs performances et leur stabilité. Une fois qu’ils sont stables, vous devez tester le système avec ces composants installés et comparer les performances à celles obtenues sur la batterie de serveurs sans ces composants. Les composants personnalisés sont souvent la cause principale des problèmes de performances et de fiabilité dans les systèmes de production.

  • Vous devez connaître la finalité de vos tests. Définissez à l’avance les objectifs des tests. S’agit-il de valider les performances de certains nouveaux composants personnalisés qui ont été développés pour la batterie de serveurs ? S’agit-il de déterminer le temps nécessaire pour analyser et indexer un ensemble de contenus ? S’agit-il de déterminer combien de demandes par seconde votre batterie de serveurs peut prendre en charge ? De nombreux objectifs différents peuvent être poursuivis pendant un test, et la première étape du développement d’un plan de test efficace consiste à déterminer vos objectifs.

  • Déterminez les paramètres que vous devez mesurer pour atteindre l’objectif de vos tests. Si vos mesures doivent porter sur la capacité de débit de votre batterie de serveurs par exemple, vous devez mesurer le taux de demandes par seconde et la latence des pages. Si vos mesures portent sur les performances de recherche, vous devez mesurer le temps d’analyse et les taux d’indexation des documents. Le fait d’établir avec précision l’objectif de vos tests vous permet de définir clairement les indicateurs de performance clés que vous devez valider pour effectuer vos tests.

Créer l’environnement de test

Une fois que vous avez établi les objectifs de vos tests, défini vos mesures et déterminé les besoins en capacité de votre batterie de serveurs (à partir des étapes 1 et 2 de ce processus), l’objectif suivant consiste à concevoir et à créer l’environnement de test. L’effort à fournir pour créer un environnement de test est souvent sous-estimé. Cet environnement doit dupliquer l’environnement de production aussi fidèlement que possible. Les fonctions et fonctionnalités que vous devez prendre en compte lors de la conception de votre environnement de test comprennent notamment les suivantes :

  • Authentification : déterminez si la batterie de serveurs utilise les services de domaine Active Directory (AD DS), l’authentification par formulaire (et si tel est le cas avec quel annuaire), l’authentification basée sur les revendications, etc. Indépendamment de l’annuaire que vous utilisez, de combien d’utilisateurs avez-vous besoin dans votre environnement de test et comment allez-vous les créer ? De combien de groupes ou rôles aurez-vous besoin et comment allez-vous les créer et les remplir ? Vous devez également vous assurer que vos services d’authentification disposent de suffisamment de ressources pour ne pas devenir un goulot d’étranglement pendant les tests.

  • DNS : déterminez les espaces de noms dont vous aurez besoin pendant les tests. Identifiez les serveurs qui répondront à ces demandes et veillez à établir un plan prévoyant quelles adresses IP seront utilisées par les différents serveurs et quelles sont les entrées DNS que vous devrez créer.

  • Équilibrage de charge : en supposant que vous utilisez plusieurs serveurs (ce qui est normalement le cas, à moins que la charge soit insuffisante pour justifier la réalisation d’un test de charge), vous devrez recourir à une solution d’équilibrage de charge. Il peut s’agir d’un périphérique d’équilibrage de charge matériel, ou vous pouvez utiliser un équilibrage de charge logiciel tel que l’équilibrage de charge réseau Windows. Déterminez ce que vous allez utiliser et notez toutes les informations de configuration dont vous aurez besoin pour que la solution choisie soit opérationnelle rapidement et efficacement. En outre, vous devez garder à l’esprit que les agents de test de charge essaient de résoudre l’adresse en une URL une fois toutes les 30 minutes. Cela signifie que vous ne devez pas utiliser un fichier d’hôtes local ou un DNS cyclique pour l’équilibrage de charge dans la mesure où les agents de test finiront probablement par solliciter le même serveur pour chaque demande, au lieu d’effectuer un équilibrage entre tous les serveurs disponibles.

  • Serveurs de test : lors de la planification de votre environnement de test, outre les serveurs de la batterie de serveurs SharePoint Server 2010, vous devez planifier les ordinateurs nécessaires à l’exécution des tests. En règle générale, cela inclut 3 serveurs, voir plus si nécessaire. Si vous utilisez Visual Studio Team System (Team Test Load Agent) pour effectuer les tests, un ordinateur servira de contrôleur de test de charge. Deux ou plusieurs ordinateurs servent généralement d’agents de test de charge. Les agents sont les ordinateurs qui récupèrent du contrôleur de test les instructions relatives aux éléments à tester et qui envoient les demandes à la batterie de serveurs SharePoint Server 2010. Les résultats des tests eux-mêmes sont stockés sur un ordinateur SQL Server. Vous ne devez pas recourir à l’ordinateur SQL Server utilisé pour la batterie de serveurs SharePoint Server 2010, car l’écriture des données de test fausserait les ressources SQL Server disponibles pour la batterie de serveurs SharePoint Server 2010. En outre, vous devez surveiller vos serveurs de test lorsque vous exécutez vos tests, de la même façon que vous surveilleriez les serveurs de la batterie de serveurs SharePoint Server 2010, ou des contrôleurs de domaine, etc., pour vous assurer que les résultats des tests sont représentatifs de la batterie de serveurs que vous êtes en train de configurer. Parfois, le contrôleur ou les agents de test de charge peuvent eux-mêmes devenir le goulot d’étranglement. Si cela se produit, le débit révélé dans votre test n’est généralement pas le débit maximal que la batterie de serveurs peut prendre en charge.

  • SQL Server : dans votre environnement de test, suivez les conseils indiqués dans les sections « Configurer SQL Server » et « Valider et surveiller les performances de stockage et de SQL Server » de l’article Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010).

  • Validation du jeu de données : lorsque vous déterminez le contenu à tester, n’oubliez pas que, dans le meilleur des cas, vous allez utiliser des données issues d’un système de production existant. Par exemple, vous pouvez sauvegarder vos bases de données de contenu à partir d’une batterie de serveurs de production, les restaurer dans votre environnement de test, puis attacher les bases de données pour insérer le contenu dans la batterie de serveurs. Chaque fois que vous exécutez des tests par rapport à des données fictives ou à un échantillon de données, vous courez le risque d’obtenir des résultats faussés en raison des différences dans votre corpus de contenu.

Si vous êtes amené à créer un échantillon de données, vous devez prendre en compte certains éléments pendant la génération de ce contenu :

  • Toutes les pages doivent être publiées ; rien ne doit être extrait.

  • La navigation doit être réaliste ; ne générez pas plus de contenu que vous seriez susceptible d’utiliser dans un environnement de production.

  • Vous devez avoir une idée des personnalisations que le site de production utilisera. Par exemple, dans la mesure du possible, les pages maîtres, feuilles de style, JavaScript, etc. doivent tous être implémentés dans l’environnement de test de la même manière que dans l’environnement de production.

  • Déterminez le nombre de niveaux d’autorisation et/ou de groupes SharePoint dont vous aurez besoin et comment vous allez associer des utilisateurs à ceux-ci.

  • Déterminez si vous devrez effectuer des importations de profils et évaluez la durée de ces opérations.

  • Déterminez si vous aurez besoin d’audiences et comment vous allez les créer et les remplir.

  • Déterminez si vous avez besoin de sources de contenu de recherche supplémentaires et ce dont vous aurez besoin pour les créer. Si vous n’avez pas besoin de les créer, déterminez si vous disposez d’un accès réseau vous permettant de les analyser.

  • Déterminer si vous disposez de suffisamment de données d’échantillonnage (documents, listes, éléments de liste, etc.). Dans le cas contraire, planifiez la création de ce contenu.

  • Veillez à utiliser un contenu unique permettant de tester la recherche correctement. Une erreur courante consiste à télécharger le même document, peut-être des centaines ou même des milliers de fois, vers différentes bibliothèques de documents avec des noms différents. Cela peut affecter les performances de recherche dans la mesure où le processeur de requêtes consacre un temps conséquent à la détection des doublons, opération qu’il n’effectuerait pas dans un environnement de production comportant du contenu réel.

Créer des tests et des outils

Une fois que l’environnement de test est fonctionnel, il est temps de créer et d’affiner les tests qui permettront de mesurer la capacité des performances de la batterie de serveurs. Cette section fera parfois spécifiquement référence à Visual Studio Team System (Team Test Load Agent), mais la plupart des concepts sont applicables indépendamment de l’outil de test de charge que vous utilisez. Pour plus d’informations sur Visual Studio Team System, voir la rubrique Visual Studio Team System (éventuellement en anglais) sur le site MSDN (https://msdn.microsoft.com/fr-fr/library/fda2bad5.aspx) (éventuellement en anglais).

Vous pouvez également utiliser le kit SharePoint LTK (Load Test Kit) en association avec VSTS pour les tests de charge des batteries de serveurs SharePoint 2010. Le kit de test de charge génère un test de charge Visual Studio Team System 2008 basé sur les journaux IIS Microsoft Office SharePoint Server 2007 et Windows SharePoint Services 3.0. Le test de charge VSTS peut être utilisé pour générer une charge de synthèse par rapport à SharePoint Foundation 2010 ou SharePoint Server 2010 dans le cadre d’un exercice de planification de la capacité ou d’un test de contrainte préalable à la mise à niveau.

Le kit de test de charge est inclus dans Microsoft SharePoint 2010 Administration Toolkit v1.0, disponible à partir du Centre de téléchargement Microsoft (éventuellement en anglais) (https://www.microsoft.com/downloads/details.aspx?familyid=718447d8-0814-427a-81c3-c9c3d84c456e\&displaylang=fr-fr) (éventuellement en anglais).

Un critère clé pour la réussite des tests est la possibilité de simuler efficacement une charge de travail réaliste en générant des demandes sur une plage étendue des données de site de test, à l’image des utilisateurs qui accèdent à une large gamme de contenu d’une batterie de serveurs de production SharePoint Server 2010. Pour ce faire, vous devrez généralement construire vos tests de façon à ce qu’ils soient pilotés par les données. Au lieu de créer des centaines de tests individuels codés en dur pour accéder à une page spécifique, vous devez utiliser seulement quelques tests qui utilisent des sources de données contenant les URL de ces éléments pour accéder dynamiquement à ce jeu de pages.

Dans Visual Studio Team System (Team Test Load Agent), une source de données peut se présenter dans plusieurs formats, mais un format de fichier CSV est souvent plus facile à gérer et à transporter entre les environnements de développement et de test. N’oubliez pas que la création de fichiers CSV avec ce contenu peut nécessiter la création d’outils personnalisés pour énumérer l’environnement basé sur SharePoint Server 2010 et enregistrer les différentes URL en cours d’utilisation.

Vous devrez peut-être utiliser des outils pour des tâches telles que les suivantes :

  • La création d’utilisateurs et de groupes dans Active Directory ou un autre magasin d’authentifications si vous utilisez l’authentification par formulaire.

  • L’énumération d’adresses URL de sites, de listes, de bibliothèques, d’éléments de liste, de documents, etc. et leur insertion dans des fichiers CSV pour les tests de charge.

  • Le téléchargement d’exemples de documents vers un ensemble de bibliothèques de documents et de sites.

  • La création de collections de sites, de sites Web, de listes, de bibliothèques, de dossiers et d’éléments de liste.

  • La création de sites Mon site.

  • La création de fichiers CSV contenant les noms d’utilisateur et les mots de passe des utilisateurs des tests ; ce sont les comptes d’utilisateurs sous lesquels les tests de charge seront exécutés. Il doit y avoir plusieurs fichiers de manière à ce que, par exemple, certains contiennent uniquement les utilisateurs administrateurs, certains contiennent d’autres utilisateurs avec des privilèges élevés (tels qu’auteur/collaborateur, gestionnaire de hiérarchies, etc.) et d’autres ne concernent que les lecteurs, etc.

  • La création d’une liste des exemples de mots clés et d’expressions de recherche.

  • Le remplissage des groupes et des niveaux d’autorisation SharePoint avec des utilisateurs et des groupes Active Directory (ou des rôles si vous utilisez l’authentification par formulaire).

Lors de la création des tests Web, vous devez en outre observer et mettre en œuvre les meilleures pratiques suivantes :

  • Enregistrez des tests Web simples comme point de départ. Ces tests comporteront des valeurs codées en dur pour les paramètres tels que l’URL, les ID, etc. Remplacez ces valeurs codées en dur par des liens provenant de vos fichiers CSV. La liaison de données avec ces valeurs dans Visual Studio Team System (Team Test Load Agent) est extrêmement simple.

  • Ayez toujours des règles de validation pour votre test. Par exemple, lors de la demande d’une page, si une erreur se produit, vous obtenez souvent la page error.aspx en réponse. Du point de vue d’un test Web, cela est assimilable à n’importe quelle réponse positive, étant donné que vous obtenez le code d’état HTTP 200 (réussite) dans les résultats des tests de charge. Bien évidemment, une erreur est quand même survenue, qui doit faire l’objet d’un suivi spécifique. La création d’une ou de plusieurs règles de validation permet de capturer la situation dans laquelle du texte spécifique est envoyé en réponse, afin que la validation échoue et que la demande soit marquée comme ayant échoué. Par exemple, dans Visual Studio Team System (Team Test Load Agent), une règle de validation simple peut être une validation ResponseUrl : elle enregistre une erreur si la page affichée après la redirection n’est pas la même page de réponse que celle enregistrée dans le test. Vous pouvez également ajouter une règle FindText qui enregistre une erreur si elle trouve l’expression « accès refusé », par exemple, dans la réponse.

  • Utilisez plusieurs utilisateurs dans des rôles différents pour les tests. Certains comportements, tels que la mise en cache de sortie, fonctionnent différemment selon les droits de l’utilisateur actuel. Par exemple, un administrateur de collection de sites ou un utilisateur authentifié disposant des droits de création ou d’approbation n’obtiendront pas de résultats mis en cache, car il est préférable qu’ils disposent systématiquement de la version de contenu la plus récente. Les utilisateurs anonymes, cependant, obtiendront le contenu mis en cache. Vous devez vous assurer que les utilisateurs des tests appartiennent à une combinaison de ces rôles qui correspond approximativement à la combinaison des utilisateurs dans l’environnement de production. Par exemple, il est probable que l’environnement de production ne compte que deux ou trois administrateurs de collection de sites, si bien que vous ne devez pas créer de tests où 10 % des demandes de page sont effectuées par des comptes d’utilisateurs qui sont des administrateurs de collection de sites pour le contenu des tests.

  • Dans Visual Studio Team System (Team Test Load Agent), l’analyse des demandes dépendantes est un attribut qui détermine si l’agent de test doit tenter de récupérer uniquement la page ou la page et toutes les demandes associées qui font partie de la page, telles que les images, les feuilles de style, les scripts, etc. Lors du test de la charge, nous ignorons généralement ces éléments pour plusieurs raisons :

    • Lorsqu’un utilisateur accède à un site pour la première fois, ces éléments sont souvent mis en cache par le navigateur local.

    • Ces éléments ne proviennent généralement pas de SQL Server dans un environnement SharePoint Server 2010. Lorsque la mise en cache BLOB est activée, ils sont en fait fournis par les serveurs Web et ne génèrent donc pas de charge pour SQL Server.

Si vous avez régulièrement un pourcentage élevé d’utilisateurs accédant à votre site pour la première fois, que vous avez désactivé la mise en cache du navigateur ou que pour une raison quelconque vous n’envisagez pas d’utiliser le cache BLOB, il peut être judicieux d’activer l’analyse des demandes dépendantes dans vos tests. Cependant, ceci est vraiment l’exception, et non la règle de base, pour la plupart des implémentations. N’oubliez pas que si vous activez cette fonctionnalité, cela peut entraîner une augmentation significative des nombres de demandes par seconde signalés par le contrôleur de test. Ces demandes sont prises en charge tellement rapidement que vous risquez de surestimer à tort la capacité réelle disponible dans la batterie de serveurs.

  • En outre, n’oubliez pas de modéliser l’activité des applications clientes. Celles-ci, telles que Microsoft Word, PowerPoint, Excel et Outlook, génèrent également des demandes destinées aux batteries de serveurs SharePoint Server 2010. Elles ajoutent une charge à l’environnement en envoyant les demandes serveur telles que l’extraction de flux RSS, l’acquisition d’informations sociales, la demande de détails sur la structure de site et de liste, la synchronisation de données, etc. Ces types de demandes doivent être inclus et modélisés si ces clients figurent dans votre implémentation.

  • Dans la plupart des cas, un test Web ne doit contenir qu’une seule demande. Il est plus facile d’optimiser l’exploitation du test et de résoudre les problèmes liés aux différentes demandes si le test ne contient qu’une seule demande. Les tests Web devront généralement contenir plusieurs demandes si l’opération qu’ils simulent est composée de plusieurs demandes. Par exemple, pour tester cet ensemble d’actions, vous aurez besoin d’un test comportant plusieurs étapes : extraction d’un document, modification, archivage et publication de celui-ci. Cela nécessite également la conservation d’un état entre les opérations ; par exemple, le même compte d’utilisateur doit être utilisé pour l’extraction, la réalisation des modifications, puis l’archivage. Ces opérations en plusieurs étapes nécessitant la conservation d’un état entre chaque étape sont mieux gérées par plusieurs demandes dans un test Web unique.

  • Testez chaque test Web individuellement. Assurez-vous que chaque test peut être accompli correctement avant de l’exécuter dans un test de charge de plus grande ampleur. Vérifiez que tous les noms des applications Web sont résolus et que les comptes d’utilisateur utilisés dans le test disposent de droits suffisants pour exécuter le test.

Les tests Web comprennent les demandes de pages individuelles, le téléchargement de documents, l’affichage d’éléments de liste, etc. Tous ces éléments sont réunis dans les tests de charge. Un test de charge est l’endroit où vous connectez tous les différents tests Web qui vont être exécutés. Chaque test Web peut se voir attribuer un pourcentage de temps d’exécution ; par exemple, si vous constatez que 10 % des demandes dans une batterie de serveurs de production sont des requêtes de recherche, dans le test de charge, vous pouvez configurer un test Web de requête de telle sorte qu’il s’exécute pendant 10 % du temps. Dans Visual Studio Team System (Team Test Load Agent), les tests de charge concernent également la configuration d’éléments tels que la combinaison de navigateurs, la combinaison de réseaux, les modèles de charge et les paramètres d’exécution.

Il existe certaines meilleures pratiques supplémentaires qui doivent être observées et mises en œuvre pour les tests de charge :

  • Dans vos tests, utilisez un ratio de lecture/écriture raisonnable. Un nombre excessif d’écritures dans un test peut avoir un impact significatif sur le débit global du test. Même sur des batteries de serveurs de collaboration, les ratios de lecture/écriture ont tendance à comporter plus de lectures que d’écritures. Pour plus d’informations, voir Performance and capacity technical case studies (SharePoint Server 2010).

  • Étudiez l’impact de toutes les autres opérations gourmandes en ressources et déterminez si elles doivent se produire pendant le test de charge. Par exemple, les opérations telles que la sauvegarde et la restauration ne sont généralement pas effectuées pendant un test de charge. Il est naturel qu’une analyse de recherche complète n’ait pas lieu pendant un test de charge, contrairement à une analyse incrémentielle. Vous devez envisager la façon dont ces tâches seront planifiées dans l’environnement de production : seront-elles exécutées aux heures de charge maximale ? Si ce n’est pas le cas, elles doivent probablement être exclues pendant le test de charge, lorsque vous essayez de déterminer la charge d’état stable maximale que vous pouvez prendre en charge pour le trafic de pointe.

  • N’utilisez pas le temps de réflexion. Le temps de réflexion est une fonctionnalité de Visual Studio Team System (Team Test Load Agent) qui vous permet de simuler la durée pendant laquelle les utilisateurs marquent une pause entre les clics effectués sur une page. Par exemple, un utilisateur peut charger une page, passer trois minutes à la lire, puis cliquer sur un lien sur la page pour accéder à un autre site. Il est presque impossible de modéliser ce comportement dans un environnement de test et une telle modélisation n’ajoute pratiquement aucune valeur aux résultats des tests. Il est difficile d’effectuer une modélisation, car la plupart des organisations ne sont pas en mesure de surveiller différents utilisateurs et le temps qui s’écoule entre chaque clic sur les différents types de sites SharePoint (tels que les sites de publication, de recherche ou de collaboration). En outre, cela n’apporte pas de valeur dans la mesure où même si un utilisateur peut faire une pause entre les demandes de pages, les serveurs basés sur SharePoint Server 2010 ne marquent pas de pause. Ces derniers reçoivent simplement un flux continu de demandes qui peut présenter des pics et des creux au fil du temps, mais ils ne demeurent pas inactifs lorsque chaque utilisateur marque une pause entre les clics sur les liens d’une page.

  • Comprenez la différence entre utilisateurs et demandes. Visual Studio Team System (Team Test Load Agent) possède un modèle de charge qui vous invite à entrer le nombre d’utilisateurs à simuler. Cela n’a rien à voir avec les utilisateurs de l’application ; il ne s’agit en fait que du nombre de threads à utiliser pour générer des demandes sur les agents de test de charge. Une erreur courante consiste à penser que si le déploiement comprend 5 000 utilisateurs, par exemple, c’est ce nombre qui doit être utilisé dans Visual Studio Team System (Team Test Load Agent), ce qui n’est pas le cas. C’est l’une des nombreuses raisons pour lesquelles lors de l’estimation des besoins liés à la planification de la capacité, il est nécessaire d’évaluer les contraintes d’utilisation en fonction du nombre de demandes par seconde et non du nombre d’utilisateurs. Dans un test de charge Visual Studio Team System (Team Test Load Agent), vous constaterez que vous pouvez souvent générer des centaines de demandes par seconde à l’aide de seulement 50 à 75 « utilisateurs » de test de charge.

  • Utilisez un modèle de charge constant pour les résultats des tests les plus fiables et reproductibles. Dans Visual Studio Team System (Team Test Load Agent), vous avez la possibilité de baser la charge sur un nombre constant d’utilisateurs (threads, comme expliqué dans le point précédent), sur un modèle de charge d’utilisateurs progressif ou sur un test d’utilisation basé sur des objectifs. Un modèle de charge progressif consiste à démarrer avec un nombre réduit d’utilisateurs, puis à ajouter progressivement des utilisateurs à quelques minutes d’intervalle. Un test d’utilisation basé sur des objectifs consiste à établir un seuil pour un certain compteur de diagnostic, tel que l’utilisation du processeur, et à tester le pilotage de la charge en faisant en sorte que ce compteur demeure entre un seuil minimal et un seuil maximal définis par vos soins. Toutefois, si vous essayez simplement de déterminer le débit maximal que la batterie de serveurs SharePoint Server 2010 peut accepter au cours des pics de charge, il est plus efficace et précis de choisir simplement un modèle de charge constante. Cela vous permet d’identifier plus facilement le volume de charge que le système peut accepter avant de commencer à dépasser régulièrement les seuils qui doivent être maintenus dans une batterie de serveurs en bon état.

Chaque fois que vous exécutez un test de charge, souvenez-vous qu’il modifie les données de la base de données. Qu’il s’agisse du téléchargement de documents, de la modification d’éléments de liste ou simplement de l’enregistrement d’activités dans la base de données d’utilisation, des données sont systématiquement écrites dans SQL Server. Pour obtenir un jeu de résultats des tests cohérent et valide à partir de chaque test de charge, vous devez disposer d’une sauvegarde avant d’exécuter le premier test de charge. À la fin de chaque test de charge, il est nécessaire d’utiliser la sauvegarde pour restaurer le contenu tel qu’il existait avant le démarrage du test.

See Also

Concepts

Vue d’ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2010
Planification de la capacité pour SharePoint Server 2010
Surveillance et gestion de SharePoint Server 2010
Surveillance de l’intégrité (SharePoint Server 2010)
Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010)