Test des performances de SharePoint Server 2013

S’APPLIQUE À :2013 2016 2019 Édition d’abonnement 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 prévoyez d'apporter des modifications à l'architecture, ou si vous souhaitez évaluer la charge utilisateur des nouvelles fonctionnalités SharePoint Server 2013, ces tests sont particulièrement importants pour vous assurer que le nouvel environnement SharePoint Server 2013 répondra aux objectifs de performances et de capacité définis.

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.

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

• 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 souhaiterez mesurer le temps d’analyse et les taux 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 utilisera 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: 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 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 les tests, un ordinateur sera 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 les performances de stockage et de SQL Server » dans l’article Stockage et SQL Server planification et configuration de la capacité (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 que l’environnement de test est opérationnel, vous devez créer et ajuster les tests qui seront utilisés pour mesurer les 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 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 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 penser vos tests de sorte 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 avoir plusieurs formats, mais un format de fichier CSV est souvent mieux adapté à la gestion et au transfert entre des 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 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 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 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. 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, 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.

  • Généralement, ces éléments ne proviennent pas de SQL Server dans un environnement SharePoint Server 2013. Lorsque la mise en cache BLOB est activée, ils sont traités par les serveurs Web et ne génèrent donc 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 faire penser que la batterie de serveurs dispose de plus de capacité qu'il n'en existe 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 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. Chaque test web peut recevoir un pourcentage de temps d’exécution : par exemple, si vous constatez que 10 % des requêtes dans 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, 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. 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.). Par ailleurs, cette modélisation n'apporte aucune réelle valeur ajoutée, car même si un délai plus ou moins long s'écoule entre les demandes de page effectuées par un utilisateur, ce n'est pas le cas sur les serveurs SharePoint Server 2013. Ces derniers ne reçoivent que des flux constants de demandes qui peuvent atteindre des pointes et des creux au fil du temps, mais ils ne restent pas inactifs chaque fois qu'un utilisateur arrête de cliquer sur des liens.

• Comprendre la différence entre les utilisateurs et les demandes. Visual Studio Team System (Team Test Load Agent) a un modèle de charge où il vous demande d’entrer le nombre d’utilisateurs à simuler. Cela n’a rien à voir avec les utilisateurs de l’application, c’est vraiment le nombre de threads qui seront utilisés sur les agents de test de charge pour générer des requêtes. 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 tentez simplement de déterminer le débit maximal que votre batterie de serveurs SharePoint Server 2013 peut maintenir au cours d'une charge maximale, il est plus efficace et plus précis de choisir un modèle de charge constant. 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, 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 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