Test des performances de SharePoint Server 2013

 

**Sapplique à :**SharePoint Server 2013 Enterprise, SharePoint Server 2013 Standard

**Dernière rubrique modifiée :**2017-08-25

**Résumé :**Découvrez comment planifier et exécuter les tests de performances d’un environnement SharePoint Server 2013.

Cet article décrit comment tester les performances de SharePoint Server 2013. La phase de test et de l’optimisation est un composant essentiel de la gestion de la capacité réelle. Vous devez tester les nouvelles architectures avant de les déployer en production et vous devez mener des tests conjointement avec les meilleures pratiques suivantes surveillance afin d’assurer les architectures de de que conception atteindre les objectifs de performances et de capacité d’acceptation. Cela vous permet d’identifier et d’optimiser les goulots d’étranglement potentiels avant que ceux-ci perturbent les utilisateurs dans un déploiement en conditions réelles. Si vous mettez à niveau un environnement de Office SharePoint Server 2007 et d’un plan pour apporter des modifications architecturales, ou estimation charge utilisateur des nouvelles fonctionnalités de SharePoint Server 2013, puis testez particulièrement important de vous assurer que votre nouvelle SharePoint Server 2013-environnement répondra aux objectifs de performances et de capacité.

Après avoir testé votre environnement, vous pouvez analyser les résultats des tests afin de déterminer les changements nécessaires pour atteindre les objectifs de performances et de capacité que vous avez définis à l’étape 1 : Modèle de l’article Planification de la capacité pour SharePoint Server 2013.

Il est recommandé de suivre les sous-étapes pour un environnement de pré-production :

  • Créez l’environnement de test imitant l’architecture initiale que vous avez conçue à l’étape 2 : Conception.

  • Remplissez l’espace de stockage avec une partie ou l’ensemble du jeu de données que vous avez identifié à l’étape 1 : Modèle.

  • Imposez une charge synthétique au système, représentant la charge de travail que vous avez identifiée à l’étape 1 : Modèle.

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

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

  • Analysez les résultats du pilote, identifiez les éventuels goulots d’étranglement et optimisez l’architecture. Effectuez de nouveaux tests si nécessaire.

  • Procédez au déploiement vers l’environnement de production.

Avant de lire cet article, nous conseillons de lire la page Vue d’ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2013.

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 comprend les éléments suivants :

  • Le matériel conçu pour fonctionner selon les objectifs de performances de production attendus. Par précaution, mesurez toujours les performances des systèmes de test.

  • Si vous disposez d’un code ou de composants personnalisés, il est important de les tester d’abord de façon isolée afin de valider leurs performances et leur stabilité. Une fois leur stabilité éprouvée, testez le système avec ces composants installés, puis comparez les performances de la batterie de serveurs sans que ces composants ne soient installés. Les composants personnalisés sont souvent la principale cause de problèmes de performances et de fiabilité dans les systèmes de production.

  • Identifiez le but de vos tests et déterminez-en préalablement les objectifs. S’agit-il de valider les performances de nouveaux composants personnalisés développés pour la batterie de serveurs ? Souhaitez-vous observer la durée d’analyse et d’indexation d’un jeu de contenus ? Voulez-vous déterminer le nombre de demandes par seconde que votre batterie de serveurs peut prendre en charge ? Un test peut avoir plusieurs objectifs et la première étape dans le développement d’un bon plan de test consiste à les identifier.

  • Déterminez la méthode selon laquelle mesurer l’objectif de votre test. Par exemple, si vous souhaitez mesurer la capacité de débit de votre batterie de serveurs, vous allez mesurer les demandes par seconde et la latence des pages. Si vous voulez mesurer les performances de recherche, vous allez mesurer la durée d’analyse et la vitesse d’indexation des documents. Si votre objectif de test est bien identifié, vous pourrez définir clairement les indicateurs de performance clés que vous devez valider afin d’exécuter vos tests.

Créer l’environnement de test

Une fois vos objectifs de test fixés, vos mesures définies et la capacité requise déterminée pour votre batterie de serveurs (aux étapes 1 et 2 du processus), l’étape suivante consiste à concevoir et à créer l’environnement de test. L’effort à déployer pour créer un environnement de test est souvent sous-estimé. Il s’agit de dupliquer l’environnement de production aussi fidèlement que possible. Certaines fonctions et fonctionnalités sont à prendre en compte lors de la conception de votre environnement de test :

  • Authentification : déterminez si la batterie de serveurs doit utiliser les services de domaine Active Directory (AD DS), l’authentification basée sur les formulaires (et si oui, quel répertoire), l’authentification basée sur les revendications, etc. Quel que soit le répertoire utilisé, de combien d’utilisateurs avez-vous besoin dans votre environnement de test et comment allez-vous les créer ? Combien de groupes ou de rôles seront nécessaires et comment allez-vous les créer et les remplir ? Vous devez également vous assurer que vous disposez de suffisamment de ressources allouées à vos services d’authentification afin d’éviter un goulot d’étranglement au cours des tests.

  • DNS : déterminez les espaces de noms nécessaires lors de vos tests. Identifiez les serveurs qui répondront à ces demandes et assurez-vous que vous avez inclus un plan contenant les adresses IP qui seront utilisées par les serveurs, ainsi que les entrées DNS à créer.

  • Équilibrage de charge : si vous utilisez plusieurs serveurs (ce qui est généralement le cas, sinon vous n’auriez pas suffisamment de charge pour justifier un test de charge), vous avez besoin d’une solution d’équilibrage de charge. Il peut s’agir d’un périphérique d’équilibrage de charge matérielle ou d’un équilibrage de charge logicielle tel que l’équilibrage de charge réseau Windows. Faites votre choix et notez toutes les informations de configuration nécessaires pour une configuration rapide et efficace. Retenez également qu’en général les agents de test de charge essayent et résolvent l’adresse en URL une fois toutes les 30 minutes uniquement. Cela implique que vous ne devez pas utiliser de fichier d’hôtes local ni de DNS tourniquet pour l’équilibrage de charge, car les agents de test risquent de toujours accéder au même serveur pour toutes les demandes plutôt que de les répartir entre tous les serveurs disponibles.

  • Serveurs de test: lorsque vous planifiez votre environnement de test, vous devez non seulement planifier pour les serveurs de la batterie de SharePoint Server 2013, vous devez également prévoir des machines nécessaires pour exécuter les tests. Qui incluent généralement les 3 serveurs au minimum ; plus peuvent être nécessaire. Si vous utilisez Visual Studio Team System (Team Test Load Agent) pour effectuer les tests, un ordinateur sera utilisé en tant que le contrôleur de test de charge. Il existe généralement 2 ou plusieurs ordinateurs qui sont utilisés comme agents de test de charge. Les agents sont les ordinateurs qui utilisent les instructions du contrôleur de test sur les éléments à tester et émettre les requêtes à la batterie de SharePoint Server 2013. Les résultats des tests eux-mêmes sont stockés sur un ordinateur SQL Server. Vous ne devez pas utiliser le même ordinateur SQL Server qui est utilisé pour la batterie de SharePoint Server 2016, parce que l’écriture des données de test s’incliner les ressources SQL Server disponibles pour la batterie de SharePoint Server 2013. Vous devez également surveiller vos serveurs de test lors de l’exécution de vos tests, la même façon que vous devez surveiller les serveurs dans la batterie de SharePoint Server 2013, 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 configurez. Parfois le contrôleur ou les agents de charge peut devenir le goulet d’étranglement eux-mêmes. Si cela produit puis le débit que vous voyez dans votre test n’est généralement pas le maximum de que la batterie de serveurs peut prendre en charge.

  • SQL Server : dans votre environnement de test, suivez les instructions énoncées 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).

  • Validation du jeu de données : lorsque vous déterminez le contenu pour lequel exécuter les tests, rappelez-vous que, dans le meilleur des cas, vous utiliserez les données 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 et les restaurer dans votre environnement de test, puis attacher les bases de données pour importer le contenu dans la batterie de serveurs. À chaque exécution des tests sur des exemples de données ou des données créées de toute pièce, vous courez le risque que vos résultats soient incohérents en raison des différences dans votre corpus de contenus.

Si vous devez créer des exemples de données, voici quelques considérations à garder à l’esprit lors de la création de ce contenu :

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

  • La navigation doit être réaliste ; ne créez pas plus d’éléments que ceux raisonnablement attendus pour une utilisation en production.

  • Vous devez avoir une idée des personnalisations qui seront utilisées dans le site de production. Par exemple, les pages maîtres, les feuilles de style, JavaScript, etc., doivent être implémentés dans l’environnement de test aussi fidèlement que possible par rapport à l’environnement de production.

  • Déterminez le nombre de groupes SharePoint et/ou les niveaux d’autorisation dont vous aurez besoin, ainsi que la façon dont vous allez y associer des utilisateurs.

  • Déterminez si vous devez effectuer des importations de profils, ainsi que la durée de ces importations.

  • Déterminez si vous avez besoin d’audiences, ainsi que leur mode de création et de remplissage.

  • 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 la création de ces sources n’est pas nécessaire, déterminez si vous devez accéder au réseau pour pouvoir les analyser.

  • Déterminez si vous disposez de suffisamment d’exemples de données (documents, listes, éléments de liste, etc.). Si non, créez un plan relatif à la méthode à employer pour créer ce contenu.

  • Prévoyez un plan pour garantir que vous disposez de suffisamment de contenu unique en vue de tester la recherche correctement. Une erreur courante est de télécharger le même document, parfois des centaines voire des milliers de fois, dans différentes bibliothèques de documents avec des noms distincts. Cette opération peut avoir un impact sur les performances de la recherche, car le processeur de requêtes va passer beaucoup de temps à effectuer des détections en double, ce qui ne serait pas le cas dans un environnement de production avec un contenu réel.

Créer des tests et des outils

Une fois l’environnement de test fonctionnel, il est temps de créer et d’ajuster les tests qui seront utilisés pour mesurer la capacité de performances de la batterie de serveurs. Cette section rend parfois référence spécifiquement à Visual Studio Team System (Team Test Load Agent), mais la plupart des concepts sont applicables, quel outil de test de charge vous utilisez. Pour plus d’informations sur Visual Studio Team System, consultez Visual Studio Team System sur le site MSDN (https://msdn.microsoft.com/en-us/library/fda2bad5.aspx) ».

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

Le kit LTK est inclus dans Microsoft SharePoint 2010 Administration Toolkit v1.0, disponible depuis le Centre de téléchargement Microsoft (https://www.microsoft.com/downloads/details.aspx?FamilyId=718447d8-0814-427a-81c3-c9c3d84c456e\&displaylang=en).

Un critère fondamental pour la réussite des tests est de pouvoir efficacement de simuler une charge de travail réaliste en générant des requêtes sur un large éventail de données du site de test, tout comme les utilisateurs accèdent à une large gamme de contenus dans une batterie de serveurs de SharePoint Server 2013 de production. Pour ce faire, vous devez généralement créer vos tests tels qu’ils sont contrôlées par les données. Au lieu de créer des centaines de tests individuels qui sont codées en dur pour accéder à une page spécifique, vous devez utiliser quelques tests qui utilisent des sources de données contenant les URL de ces éléments pour accéder dynamiquement à cet ensemble de pages.

Dans Visual Studio Team System (Team Test Load Agent), une source de données peut se présenter sous différents formats, mais un format de fichier CSV est souvent plus facile à gérer et les transports entre les environnements de développement et de test. Gardez à l’esprit que la création de fichiers CSV avec ce contenu peut nécessiter la création d’outils personnalisés à énumérer le SharePoint Server 2013-environnement et enregistrement les différentes des URL basées sur en cours d’utilisation.

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

  • Création d’utilisateurs et de groupes dans Active Directory ou une autre banque d’authentification si vous utilisez l’authentification basée sur les formulaires

  • Énumération des URL des sites, listes, bibliothèques, éléments de liste, documents, etc., et ajout de ces derniers à des fichiers CSV à des fins de test de charge

  • Téléchargement d’exemples de documents dans un ensemble de bibliothèques de documents et de sites

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

  • Création de sites Mon site

  • Création de fichiers CSV comportant les noms d’utilisateur et les mots de passe des utilisateurs de test. Il s’agit des comptes d’utilisateur que les tests de charge emploieront. Plusieurs fichiers doivent être utilisés de sorte que, par exemple, certains ne contiennent que des utilisateurs administrateurs, d’autres que des utilisateurs avec des privilèges élevés (auteur/contributeur, gestionnaire de hiérarchies, etc.), d’autres uniquement des utilisateurs en lecture seule, etc.

  • Création d’une liste d’exemples de mots clés et d’expressions de recherche

  • 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 basée sur les formulaires)

Lors de la création de tests Web, vous devez observer d’autres meilleures pratiques, à savoir :

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

  • Utilisez toujours des règles de validation pour votre test. Par exemple, lors de la demande d’une page, en cas d’erreur, vous obtenez souvent la page error.aspx en guise de réponse. Dans le cadre d’un test Web, elle apparaît comme une réponse positive, car vous obtenez le code d’état HTTP 200 (réussi) dans les résultats de test de charge. Toutefois, une erreur est survenue et doit faire l’objet d’un suivi différent. Créer une ou plusieurs règles de validation vous permet de traquer un certain type de texte envoyé comme réponse afin que la validation échoue et que la demande soit marquée comme un échec. Par exemple, dans Visual Studio Team System (Team Test Load Agent), une règle de validation simple peut être une validation ResponseUrl, qui enregistre un échec si la page qui est affichée après une redirection n’est pas la même page de réponse que celle qui est enregistrée dans le test. Vous pouvez également ajouter une règle FindText, qui enregistre un échec si elle détecte le terme « accès refusé » dans la réponse, par exemple.

  • Utilisez plusieurs utilisateurs à différents rôles pour les tests. Certains comportements, tels que la mise en cache de sortie, fonctionnent différemment selon les droits de l’utilisateur en cours. Par exemple, un administrateur de collection de sites ou un utilisateur authentifié disposant de droits d’approbation ou de création n’obtiendra pas de résultats mis en cache, car il doit toujours accéder à la version la plus récente du contenu. Les utilisateurs anonymes, toutefois, bénéficieront du contenu mis en cache. Vous devez vous assurer que les utilisateurs de test disposent de différents rôles afin qu’ils soient représentatifs de la diversité des utilisateurs de l’environnement de production. Par exemple, en production, il n’existe probablement que deux ou trois administrateurs de collection de sites ; vous ne devez donc pas créer de tests dans lesquels 10 % des demandes de page sont formulées par des comptes d’utilisateur qui sont des administrateurs de collection de sites.

  • L’analyse des demandes dépendantes est un attribut de Visual Studio Team System (Team Test Load Agent) 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 en font partie, comme les images, les feuilles de style, les scripts, etc. Lors des tests de charge, nous ignorons généralement ces éléments pour les raisons suivantes :

    • 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 sont généralement livrés à partir de SQL Server dans un SharePoint Server 2013-environnement. BLOB, mise en cache est activée, ils sont en revanche pris en charge par les serveurs Web afin qu’ils ne génèrent pas charge de SQL Server.

Si votre site présente généralement un pourcentage élevé de nouveaux utilisateurs, que vous avez désactivé la mise en cache du navigateur ou que vous décidez de ne pas utiliser la mise en cache BLOB, il peut être utile d’activer l’analyse des demandes dépendantes dans vos tests. Cependant, il s’agit là d’une exception et cette règle n’est pas applicable à la plupart des implémentations. Sachez que si vous activez cette fonction, le nombre de demandes par seconde signalées par le contrôleur de test peut considérablement augmenter. Ces demandes sont traitées si rapidement qu’elles peuvent vous faire penser que la batterie de serveurs dispose de plus de capacité qu’il n’en existe réellement.

  • N’oubliez pas d’activité ainsi que du modèle client application. Les applications clientes, telles que Microsoft Word, PowerPoint, Excel et Outlook génèrent des demandes ainsi que les groupes de SharePoint Server 2013. Ils ajoutent de charge à l’environnement en envoyant des requêtes du serveur, telles que la récupération de flux RSS, acquisition d’informations sociales, demander des détails sur la structure de site et de liste, la synchronisation des données, etc.. Ces types de demandes doivent être inclus et modélisés si vous avez des clients dans votre implémentation.

  • Dans la plupart des cas, un test Web doit contenir une demande unique. Il est plus facile d’ajuster et de résoudre les problèmes liés au test et aux demandes individuelles si le test ne contient qu’une seule demande. Les tests Web contiennent généralement plusieurs demandes si l’opération qu’ils simulent en compte plusieurs. Par exemple, pour tester l’ensemble d’actions « extraction, modification, archivage et publication d’un document », vous aurez besoin d’un test à plusieurs étapes. Ce type de test requiert également la conservation de l’état entre les étapes (par exemple, le même compte d’utilisateur doit être utilisé pour l’extraction, les modifications et l’archivage du document). Ces opérations en plusieurs étapes, qui requièrent un état constant entre chaque étape, sont mieux traitées par plusieurs demandes dans un test Web unique.

  • Contrôlez chaque test Web individuellement. Assurez-vous que chaque test peut être réalisé correctement avant de l’exécuter dans le cadre d’un test de charge plus important. Vérifiez que tous les noms des applications Web sont résolus et que les comptes d’utilisateur employés dans le test disposent de droits suffisants pour exécuter le test.

Les tests Web contiennent les demandes relatives aux pages individuelles, au téléchargement de documents, à l’affichage des éléments de liste, etc. Toutes ces demandes sont regroupées dans des tests de charge. Un test de charge rassemble les différents tests Web qui vont être exécutés. Un pourcentage de temps d’exécution peut être attribué à chaque test Web (par exemple, si vous constatez que 10 % des demandes émises dans une batterie de serveurs de production sont des requêtes de recherche, vous pouvez configurer un test Web approprié sur 10 % du temps dans le test de charge). 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.

Les meilleures pratiques supplémentaires suivantes doivent être observées pour les tests de charge :

  • Utilisez un rapport lecture/écriture raisonnable dans vos tests. La surcharge en nombre d’écritures dans un test peut avoir une incidence significative sur le débit global du test. Même sur les batteries de serveurs de collaboration, les rapports lecture/écriture ont tendance à présenter beaucoup plus de lectures que d’écritures.

  • Tenez compte de l’impact d’autres opérations consommatrices de ressources et déterminez si elles doivent être exécutées lors du test de charge. Par exemple, les opérations de sauvegarde et de restauration ne sont généralement pas exécutées lors d’un test de charge. Une analyse de recherche complète n’est en général pas effectuée pendant un test de charge, tandis qu’une analyse incrémentielle peut s’avérer normale. Vous devez tenir compte de la planification de ces tâches dans un environnement de production : seront-elles exécutées pendant les temps de charge maximale ? Si ce n’est pas le cas, vous pouvez probablement les exclure des tests de charge, lorsque vous tentez de déterminer l’état de charge stable maximal que vous pouvez prendre en charge pour le trafic de pointe.

  • N’utilisez pas les temps de réflexion. Temps de réflexion sont une fonctionnalité de Visual Studio Team System (Team Test Load Agent) qui vous permettent de simuler l’heure à laquelle les utilisateurs pause entre les clics sur une page. Par exemple un utilisateur typique peut charger une page, passent trois minutes lire, puis cliquez sur un lien sur la page pour visiter un autre site. Essayez ce modèle dans un environnement de test est presque impossible à réaliser correctement et efficacement valeur n’ajoute pas aux résultats des tests. Il est difficile de modèle, car la plupart des organisations ne permettent de surveiller les différents utilisateurs et le temps qu’ils passent entre clique sur différents types de sites SharePoint (comme la publication et la recherche et la collaboration, etc..). Elle aussi ne vraiment ajoute valeur parce que même si un utilisateur peut s’interrompre entre les demandes de page, le SharePoint Server 2013-n’est pas le cas de serveurs. Ils obtiennent seulement un flux continu de requêtes qui peuvent avoir des pics et les creux au fil du temps, mais ils ne s’attendent pas cause d’inactivité que chaque utilisateur est maintenu entre en cliquant sur des liens sur une page.

  • Faites la différence entre utilisateurs et demandes. Visual Studio Team System (Team Test Load Agent) comporte un modèle de charge dans lequel vous êtes invité à entrer le nombre d’utilisateurs à simuler. Cette valeur ne correspond pas aux utilisateurs d’application ; il s’agit simplement du nombre de threads qui seront utilisés sur les agents de test de charge pour générer des demandes. Une erreur courante est de penser que si le déploiement comporte 5 000 utilisateurs, par exemple, 5 000 est le nombre à utiliser dans Visual Studio Team System (Team Test Load Agent). C’est faux. C’est une des nombreuses raisons pour lesquelles les exigences d’utilisation doivent être basées sur le nombre de demandes par seconde et non sur le nombre d’utilisateurs lors de l’estimation des besoins de planification de la capacité. Dans un test de charge Visual Studio Team System (Team Test Load Agent), vous découvrirez que vous pouvez souvent générer des centaines de demandes par seconde avec seulement 50 à 75 « utilisateurs » de test de charge.

  • Utiliser un modèle de charge constante pour les résultats des tests plus fiable et reproductible. Dans Visual Studio Team System (Team Test Load Agent) vous disposez de baser charger sur un nombre constant d’utilisateurs (threads, comme expliqué dans le point précédent), un par paliers d’un modèle de charge d’utilisateurs ou un objectif en fonction de tests d’utilisation. Un modèle de charge par paliers est lorsque vous démarrez avec un petit nombre d’utilisateurs, puis « étape » ajoutant des utilisateurs supplémentaires à intervalles de quelques minutes. Un test d’utilisation en fonction des objectifs est lorsque vous définissez un seuil pour un certain compteur diagnostic, comme l’utilisation du processeur, et les tentatives de test orienter la charge de conserver ce compteur entre un seuil minimum et maximum que vous définissez pour qu’elle. Toutefois, si vous tentez simplement déterminer le débit maximal que votre batterie SharePoint Server 2013 peut supporter aux heures de pointe, il est plus efficace et plus précise de simplement choisir un modèle de charge constante. Qui vous permet d’identifier plus facilement la charge du système peut prendre avant de commencer à régulièrement dépassent les seuils qui doivent être conservées dans une batterie en bon état.

Chaque fois que vous exécutez un test de charge, rappelez-vous que cette opération modifie les données présentes dans la base de données. Qu’il s’agisse de télécharger des documents, de modifier des éléments de liste ou simplement d’enregistrer l’activité dans la base de données d’utilisation, des données seront écrites dans SQL Server. Pour garantir un ensemble de résultats de test cohérent et valable pour chaque test de charge, pensez à effectuer une sauvegarde avant d’exécuter le premier test de charge. Une fois qu’un test est terminé, utilisez la sauvegarde pour restaurer le contenu tel qu’il était avant le début du test.

See also

Planification de la capacité pour SharePoint Server 2013
Analyse et maintenance de SharePoint Server 2013
Surveillance et création de rapports dans SharePoint Server 2016
Limitations et frontières logicielles pour SharePoint Server 2016

Vue d’ensemble de la gestion et du dimensionnement de la capacité pour SharePoint Server 2013