Test des performances de SharePoint Server 2013

S’APPLIQUE À :2013 2016 2019 Subscription Edition SharePoint dans Microsoft 365

Cet article décrit comment tester les performances de SharePoint Server 2013. L'étape de test et d'optimisation est une composante essentielle d'une gestion efficace de la capacité. Vous devez tester les nouvelles architectures avant de les déployer en production et effectuer des tests d’acceptation avec les meilleures pratiques de supervision suivantes afin de vous assurer que les architectures que vous concevez atteignent les objectifs de performances et de capacité. Cela vous permet d'identifier et de corriger les éventuels goulots d'étranglement avant qu'ils n'aient une incidence sur les utilisateurs dans un déploiement dynamique. Si vous effectuez une mise à niveau à partir d’un environnement Office SharePoint Server 2007 et que vous envisagez d’apporter des modifications architecturales, ou si vous estimez la charge utilisateur des nouvelles fonctionnalités de SharePoint Server 2013, les tests sont importants pour vous assurer que votre nouvel environnement SharePoint Server 2013 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 les modifications à apporter afin d’atteindre les objectifs de performances et de capacité que vous avez établis à l’étape 1 : Modèle de planification de capacité pour SharePoint Server 2013.

Voici les sous-étapes recommandées que vous devez suivre pour la 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élisation.

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

• 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.

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 personnalisé ou d’un composant personnalisé, il est important que vous testiez d’abord 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 à la batterie de serveurs sans qu’ils 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.

• Connaître l’objectif de vos tests. Comprenez à l’avance quels sont vos objectifs de test. 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 voir le temps nécessaire à l’analyse et à l’indexation d’un ensemble de contenu ? S’agit-il de déterminer le nombre de demandes par seconde que votre batterie de serveurs peut prendre en charge ? Il peut y avoir de nombreux objectifs différents au cours d’un test, et la première étape de l’élaboration d’un bon plan de test consiste à décider quels sont vos objectifs.

• Déterminez la méthode selon laquelle mesurer l'objectif de votre test. Si vous souhaitez mesurer la capacité de débit de votre batterie de serveurs, par exemple, vous souhaiterez mesurer le RPS et la latence des pages. Si vous mesurez les performances de recherche, vous pouvez mesurer le temps d’analyse et documenter les taux d’indexation. 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 utilisera les services de domaine Active Directory (AD DS), l’authentification basée sur les formulaires (et, le cas échéant, avec quel répertoire), l’authentification basée sur les revendications, etc. Quel que soit le répertoire que vous utilisez, 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 allez-vous avoir besoin 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 pour qu’elles ne deviennent pas un goulot d’étranglement pendant les tests.

• DNS : connaissez les espaces de noms dont vous aurez besoin pendant vos tests. Identifiez les serveurs qui répondent à ces demandes et vérifiez que vous avez inclus un plan qui contient les adresses IP qui seront utilisées par les serveurs et les entrées DNS que vous devez créer.

• Équilibrage de charge : en supposant que vous utilisez plusieurs serveurs (ce que vous feriez normalement ou que vous n’auriez probablement pas assez de charge pour justifier des tests de charge), vous aurez besoin d’un type de solution d’équilibreur 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. Déterminez ce que vous allez utiliser et notez toutes les informations de configuration dont vous aurez besoin pour les configurer rapidement et efficacement. Une autre chose à retenir est que les agents de test de charge essaient généralement de résoudre l’adresse en une URL une seule fois toutes les 30 minutes. Cela signifie que vous ne devez pas utiliser un fichier d’hôtes local ou un DNS par tourniquet (round robin) pour l’équilibrage de charge, car les agents de test finissent probablement par accéder au même serveur pour chaque requête, au lieu d’effectuer un équilibrage autour de tous les serveurs disponibles.

• Serveurs de test: lorsque vous planifiez votre environnement de test, vous devez non seulement planifier les serveurs de la batterie de serveurs SharePoint Server 2013, mais aussi les ordinateurs nécessaires pour exécuter les tests. En règle générale, cela inclut au minimum trois serveurs ; d’autres peuvent être nécessaires. Si vous utilisez Visual Studio Team System (Team Test Load Agent) pour effectuer le test, un ordinateur est utilisé comme contrôleur de test de charge. Il y a généralement deux machines ou plus qui sont utilisées comme agents de test de charge. Les agents sont des ordinateurs qui reçoivent des instructions du contrôleur de test concernant les éléments à tester et qui envoient les demandes à la batterie de serveurs SharePoint Server 2013. Les résultats des tests sont stockés sur un ordinateur SQL Server. Vous ne devez pas utiliser le même ordinateur SQL Server que celui utilisé pour la batterie de serveurs SharePoint Server 2016, car l’écriture des données de test fausse les ressources SQL Server disponibles pour la batterie de serveurs SharePoint Server 2013. Vous devez également surveiller les serveurs de test lors de l'exécution des tests, comme pour la batterie SharePoint Server 2013 ou les contrôleurs de domaine, etc., afin de vous assurer que les résultats des tests reflètent la batterie de serveurs que vous configurez. Parfois, les agents de charge ou le contrôleur peuvent devenir eux-mêmes des goulots d'étranglement. Si cela se produit, le débit, que vous voyez dans votre test, n’est généralement pas la batterie maximale que la batterie peut prendre en charge.

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

• Validation du jeu de données : lorsque vous décidez du contenu sur lequel vous allez exécuter des tests, n’oubliez pas 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 de niveaux d’autorisation dont vous aurez besoin, et comment vous allez associer des utilisateurs à ces groupes.

• 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 ce n’est pas le cas, créez un plan pour la façon dont vous allez 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 que l’environnement de test est fonctionnel, il est temps de créer et d’affiner les tests qui seront utilisés pour mesurer la capacité de performances de la batterie de serveurs. Cette section fera parfois référence à Visual Studio Team System (Team Test Load Agent) en particulier, mais de nombreux concepts s'appliquent quel que soit l'outil de test de charge utilisé. Pour plus d’informations sur les outils de test disponibles pour Azure DevOps (anciennement VSTS), consultez Vue d’ensemble des outils DevOps pour Azure DevOps.

Vous pouvez également utiliser le Kit de test de charge SharePoint (LTK) avec VSTS pour le test de 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 peut être utilisé pour générer une charge synthétique sur 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 de test de charge est inclus dans microsoft SharePoint 2010 Administration Toolkit v2.0, disponible dans le Centre de téléchargement Microsoft.

Un critère essentiel à la réussite des tests est de pouvoir simuler efficacement une charge de travail réaliste en générant des demandes dans l'ensemble des données du site de test, comme des utilisateurs accédant à un large éventail de contenu dans une batterie de serveurs de production SharePoint Server 2013. Pour ce faire, vous devez généralement construire vos tests afin qu’ils soient pilotés par les données. Plutôt que de créer des centaines de tests individuels codés en dur pour accéder à une page spécifique, préférez mettre au point quelques tests qui emploient des sources de données contenant les URL des éléments permettant d'accéder de façon dynamique à l'ensemble de pages.

Dans Visual Studio Team System (Team Test Load Agent), une source de données peut être dans différents formats, mais un format de fichier CSV est souvent plus facile à gérer et à transporter entre les environnements de développement et de test. Créer des fichiers CSV avec ce contenu peut nécessiter la création d'outils personnalisés afin d'énumérer les environnements SharePoint Server 2013 et d'enregistrer les différentes URL utilisées.

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 avec des noms d’utilisateur et des mots de passe pour les utilisateurs de test ; il s’agit des comptes d’utilisateur que les tests de charge exécuteront. Il doit y avoir plusieurs fichiers de sorte que, par exemple, certains contiennent uniquement des utilisateurs administrateur, d’autres avec des privilèges élevés (comme auteur/contributeur, gestionnaire de hiérarchie, etc.), et d’autres ne sont que des lecteurs, etc.

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

• Remplissage des groupes SharePoint et des niveaux d’autorisation 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 des tests web, vous devez observer et implémenter d’autres bonnes pratiques. En voici la liste :

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

• Utilisez 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 error.aspx page en réponse. Du point de vue d’un test web, il apparaît comme une autre réponse positive, car vous obtenez un code d’état HTTP de 200 (réussite) dans les résultats du 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 : elle enregistre un échec si la page rendue après les redirections 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 un échec s’il trouve le mot « accès refusé », par exemple, dans la réponse.

• 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 les résultats mis en cache, car nous voulons toujours qu’ils voient 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’y a probablement que deux ou trois administrateurs de collection de sites. Par conséquent, vous ne devez pas créer de tests où 10 % des demandes de page sont effectuées par des comptes d’utilisateur qui sont des administrateurs de collection de sites sur le contenu de test.

• 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.

  • Généralement, ces éléments ne proviennent pas de SQL Server dans un environnement SharePoint Server 2013. Une fois la mise en cache d’objets blob activée, ils sont plutôt pris en charge par les serveurs web, de sorte qu’ils ne génèrent pas de charge 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 induire en erreur en pensant qu’il y a plus de capacité disponible dans la batterie de serveurs qu’il n’y en a réellement.

• N’oubliez pas de modéliser l’activité de l’application cliente. Les applications clientes, telles que Microsoft Word, PowerPoint, Excel et Outlook, génèrent également des requêtes vers les batteries de serveurs SharePoint Server 2013. Elles ajoutent une charge à l’environnement en envoyant des requêtes de serveur, telles que la récupération de flux RSS, l’obtention d’informations sociales, la demande de détails sur le site et la structure de liste, la synchronisation des données, etc. Ces types de demande doivent être inclus et modélisés si ces clients figurent 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 doivent généralement contenir plusieurs demandes si l’opération qu’ils simulent est composée de plusieurs requêtes. Par exemple, pour tester cet ensemble d’actions, vous aurez besoin d’un test avec plusieurs étapes : extraire un document, le modifier, l’archiver et le publier. 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. Chaque test web peut recevoir un pourcentage de temps d’exécution : par exemple, si vous constatez que 10 % des requêtes d’une batterie de serveurs de production sont des requêtes de recherche, dans le test de charge, vous configurez un test web de requête pour qu’il s’exécute 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.

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, ils doivent probablement être exclus pendant le test de charge, lorsque vous essayez de déterminer la charge maximale à l’état stable que vous pouvez prendre en charge pour le trafic de pointe.

• N'utilisez pas les temps de réflexion. Il s'agit d'une fonctionnalité de Visual Studio Team System (Team Test Load Agent) qui vous permet de simuler le délai écoulé entre les différents clics d'un utilisateur sur une page. Par exemple, un utilisateur standard peut charger une page, passer trois minutes à la lire, puis cliquer sur un lien vers un autre site. Tenter de modéliser correctement ces actions dans un environnement de test est pratiquement impossible et n'ajoute aucune valeur aux résultats des tests. La modélisation de ce comportement est difficile à réaliser car la plupart des organisations ne disposent d'aucune méthode permettant de surveiller les utilisateurs et le délai écoulé entre les clics sur différents types de site SharePoint (pour la publication, la recherche, la collaboration, etc.). Il n’ajoute pas non plus vraiment de valeur, car même si un utilisateur peut suspendre entre les demandes de page, les serveurs basés sur SharePoint Server 2013 ne le font pas. Ils obtiennent simplement un flux constant de demandes qui peuvent avoir des pics et des vallées au fil du temps, mais ils n’attendent pas sans attendre pendant que chaque utilisateur s’interrompt entre les liens cliquant sur une page.

• Comprendre la différence entre les utilisateurs et les demandes. Visual Studio Team System (Team Test Load Agent) a un modèle de charge dans lequel il vous demande d’entrer le nombre d’utilisateurs à simuler. Cela n’a rien à voir avec les utilisateurs de l’application, mais uniquement le nombre de threads qui seront utilisés sur les agents de test de charge pour générer des demandes. Une erreur courante consiste à penser que si le déploiement a 5 000 utilisateurs, par exemple, alors 5 000 est le nombre qui doit être utilisé dans Visual Studio Team System (Team Test Load Agent), ce n’est pas le cas ! C’est l’une des nombreuses raisons pour lesquelles, lors de l’estimation des besoins de planification de la capacité, les exigences d’utilisation doivent être basées sur le nombre de demandes par seconde et non sur le 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 requêtes par seconde à l’aide de seulement 50 à 75 « utilisateurs » de test de charge.

• Utilisez un modèle de charge constant pour obtenir des résultats de test reproductibles et fiables. 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), un modèle de charge accru d’utilisateurs ou un test d’utilisation basé sur des objectifs. Un modèle de charge croissant permet de commencer avec un nombre d'utilisateurs restreint, puis d'en ajouter à intervalles réguliers de quelques minutes. Un test d'utilisation en fonction d'objectifs consiste à établir un seuil pour un certain compteur de diagnostic, comme l'utilisation de l'UC, tandis que le test tente d'amener la charge à maintenir ce compteur entre le seuil minimal et le seuil maximal définis. Toutefois, si vous essayez simplement de déterminer le débit maximal que votre batterie de serveurs SharePoint Server 2013 peut supporter pendant les 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 la charge que le système peut supporter sans dépasser les seuils à maintenir dans une batterie de serveurs intègre.

Chaque fois que vous exécutez un test de charge, n’oubliez pas qu’il modifie les données de 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 chaque test de charge terminé, la sauvegarde doit être utilisée pour restaurer le contenu à la manière, c’était avant le démarrage du test.

Voir aussi

Concepts

Planification de la capacité pour SharePoint Server 2013

Analyse et maintenance de SharePoint Server 2013

Limitations et frontières logicielles pour SharePoint Server 2016

Autres ressources

Capacity management and sizing overview for SharePoint Server 2013