Estimer les performances et la capacité requises pour les environnements de collaboration de division (SharePoint Server 2013)

 

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

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

Résumé : Utilisez les résultats des tests et les recommandations pour estimer les besoins en performances et en capacité pour un environnement de collaboration de division pour SharePoint Server 2013.

Cet article fournit des instructions sur les performances et la planification des capacités pour une solution de collaboration division basée sur SharePoint Server 2013. Les informations suivantes sont incluses dans cet article :

• Spécifications d’environnement de laboratoire de test, telles que le matériel, la topologie de batterie de serveurs et la configuration

• Charge de travail de la batterie de serveurs test et jeu de données ayant généré la charge de test

• Résultats des tests et analyse qui démontrent et expliquent les tendances du débit, de la latence et de la demande matérielle sous charge à différentes échelles

Vous pouvez utiliser les informations contenues dans cet article pour comprendre les caractéristiques du scénario de charges normale et maximale et pour évaluer la variation des tendances de performances lorsque la charge des serveurs de la batterie augmente. Cet article peut également vous aider à déterminer un point de départ approprié pour la planification de votre architecture et à comprendre les éléments à prendre en compte lorsque vous développez un plan pour maintenir des niveaux de performances acceptables en charge maximale.

Dans cet article :

• Introduction to this environment

• Glossary

• Overview

• Specifications

• Results and analysis

Introduction

Cet article explique comment mettre à l’échelle des serveurs dans une solution de collaboration division SharePoint Server 2013. Une solution de collaboration division est un déploiement de SharePoint Server 2013 qui a le moins d’ordinateurs impliqués dans les activités de collaboration à une solution de collaboration d’entreprise. Cet article suppose qu’une division est une organisation à l’intérieur d’une entreprise qui a des employés de 1 000 à 10 000.

Des scénarios différents comporteront des exigences différentes. Par conséquent, complétez ces instructions avec des tests supplémentaires sur votre propre matériel et dans votre propre environnement. Si votre charge de travail et conception planifiées ressemblent à l’environnement décrit dans cet article, vous pouvez tirer des conclusions concernant les performances à attendre lorsque vous faites monter en puissance votre environnement.

En lisant cet article, vous découvrirez les éléments suivants :

• Spécifications, ce qui comprend le matériel, la topologie et la configuration

• Charge de travail, ce qui comprend une analyse de la demande sur la batterie de serveurs, le nombre d’utilisateurs et les caractéristiques d’utilisation

• Jeu de données, notamment la taille des bases de données et les types de contenu

• Résultats des tests et analyse pour la montée en puissance des serveurs web

Avant de lire cet article, lisez les articles suivants pour vous assurer que vous comprenez les concepts essentiels de la gestion de capacité dans Limitations et frontières logicielles pour SharePoint 2013SharePoint Server 2013.

• Gestion et dimensionnement de la capacité pour SharePoint Server 2013

• Estimer les performances et la capacité requises pour les environnements de collaboration intranet des entreprises (SharePoint Server 2013)

Glossaire

La liste suivante contient les définitions des termes clés présents dans cet article.

• RPS (Requests per second) : demandes par seconde, soit le nombre de demandes qu’une batterie de serveurs ou un serveur reçoit en 1 seconde. C’est une mesure courante de la charge d’un serveur ou d’une batterie de serveurs.

  Notes

  Les demandes sont différentes des chargements de page. Une page contient plusieurs composants et chacun de ces composants crée une ou plusieurs demandes lorsqu’un navigateur charge la page. Un chargement de page crée plusieurs demandes. En règle générale, les vérifications et les événements d’authentification qui utilisent très peu de ressources ne sont pas comptabilisés dans le calcul RPS.

• Zone verte : la zone verte représente un ensemble défini de caractéristiques de charge dans des conditions de fonctionnement normales, jusqu’aux charges maximales journalières attendues. Une batterie de serveurs dans cette plage doit pouvoir soutenir des temps de réponse et une latence acceptables.

  Il s’agit de l’état dans lequel le serveur peut respecter l’ensemble des critères suivants :

  • Latence côté serveur inférieure à 1 seconde pour au moins 75 % des demandes.

  • Utilisation moyenne du processeur inférieure à 60 % pour tous les serveurs de la batterie.

    Notes

    Aucune analyse de recherche active n’a été exécuté dans notre environnement de laboratoire. Par conséquent, l’utilisation du processeur du serveur de base de données a été maintenue à environ 50 % ou moins pour réserver 10 % à la charge de l’analyse de recherche. Cela signifie que le gouverneur de ressources SQL Server est utilisé en production pour que la charge de l’analyse de recherche n’utilise pas plus de 10 % du processeur.

  • Taux d’échec inférieur à 0,01 %.

• Zone rouge (max.) : la zone rouge représente un ensemble défini de caractéristiques de charge dans les conditions de fonctionnement maximales. Lorsqu’elle est en zone rouge, la batterie de serveurs reçoit des demandes de ressources temporaires très élevées qu’elle ne peut gérer que pendant des périodes limitées avant que des défaillances ou d’autres problèmes de fiabilité surviennent.

  Il s’agit de l’état dans lequel le serveur peut respecter l’ensemble des critères suivants pendant une durée limitée :

  • La fonctionnalité de limitation de requêtes HTTP est activée, mais aucune erreur 503 (Serveur occupé) n’a été renvoyée.

  • Taux d’échec inférieur à 0,1 %.

  • Latence côté serveur inférieure à 3 secondes pour au moins 75 % des demandes.

  • Utilisation moyenne du processeur inférieure à 90 % environ pour tous les serveurs de la batterie (hormis les serveurs de base de données).

  • Utilisation moyenne du processeur du serveur de base de données inférieure à 50 % environ, ce qui permet de réserver une grande charge de traitement pour l’analyse de recherche.

• AxBxC (notation du graphique) : nombre de serveurs web, nombre de serveurs d’applications et nombre de serveurs de base de données dans une batterie, respectivement. Par exemple, 10x1x1 signifie que l’environnement comporte 10 serveurs web, 1 serveur d’applications et 1 serveur de base de données.

• MDF et LDF : fichiers physiques SQL Server. Pour plus d’informations, voir Architecture des fichiers et des groupes de fichiers.

Vue d’ensemble

Cette section fournit une vue d’ensemble de notre approche de montée en charge et de notre méthodologie de test.

Approche de montée en puissance

Cette section décrit l’approche que nous avons adoptée pour faire monter en puissance notre environnement de laboratoire. Cette approche va vous permettre de trouver la meilleure configuration pour votre charge de travail :

• Nous avons fait monter en puissance les serveurs web jusqu’à ce que quatre serveurs web soient utilisés. Chaque serveur exécute le service de cache distribué.

• Nous avons ajouté un serveur dédié exécutant ce service.

• Nous avons désactivé le service de cache distribué sur les serveurs Web.

• Nous avons fait monter en puissance d’autres serveurs web jusqu’au maximum pour l’étendue du test.

Remarques sur la méthodologie et les tests

Étant donné que cet article contient des résultats provenant d’un environnement de laboratoire de test, nous avons pu faire en sorte que certains facteurs affichent des aspects spécifiques des performances pour cette charge de travail. En outre, certains éléments de l’environnement de production, qui figurent dans la liste suivante, ont été écartés de l’environnement de test pour simplifier la charge de traitement des tests.

• Entre deux séries de tests, nous avons modifié uniquement une variable à la fois pour faciliter la comparaison des résultats entre chaque série.

• Les serveurs de base de données ne faisaient partie d’aucun cluster car la redondance n’était pas nécessaire pour la finalité de ces tests.

• L’analyse de recherche n’était pas exécutée pendant les tests. Évidemment, il est possible qu’elle soit exécutée dans un environnement de production. Pour prendre cette variable en compte, nous avons réduit l’utilisation du processeur SQL Server dans nos définitions de « zone verte » et de « zone rouge » pour adapter les ressources qu’une analyse de recherche utiliserait habituellement pendant les tests.

Spécifications

Cette section fournit des détails sur le matériel, les logiciels, la topologie et la configuration de notre environnement de laboratoire de test.

Matériel

Les sections suivantes décrivent le matériel que nous avons utilisé dans notre environnement de laboratoire de test.

Hôtes Hyper-V

Nous avons utilisé six hôtes Hyper-V configurés de manière identique pour nos tests. Chaque hôte exécute une à deux machines virtuelles.

Matériel de l’hôte	Valeur
Processeurs	2 processeurs quadruple cœur 2,49 GHz
Mémoire RAM	32 Go
Système d’exploitation	Windows Server 2008 R2 SP1
Nombre de cartes réseau	2
Vitesse de la carte réseau	1 gigabit

Serveurs web virtuels et serveurs d’applications

Notre batterie de serveurs de test utilise huit serveurs web virtuels. Nous utilisons également un serveur virtuel dédié qui exécute le service de cache distribué.

Matériel virtuel	WFE1-8 et DC1
Processeurs	4 processeurs virtuels
Mémoire RAM	12 Go
Système d’exploitation	Windows Server 2008 R2 SP1
Taille du lecteur SharePoint	100 Go
Nombre de cartes réseau	2
Vitesse de la carte réseau	10 gigabits (trafic entre les hôtes limité à la vitesse de la carte réseau de l’hôte)
Authentification	Windows NTLM
Type d’équilibrage de la charge	F5 Big-IP
Services exécutés en local	WFE 1-8 : services fédérés de base. Ceci comprend les suivants : service du minuteur SharePoint, service de suivi, Word Automation Services, Excel Services et Service de code en mode bac à sable Microsoft SharePoint Foundation. DC1 : service de cache distribué.

Serveurs de base de données

Dans nos tests, nous utilisons un serveur de base de données physique et avons exécuté l’instance SQL Server par défaut qui stocke les bases de données SharePoint. Nous ne suivons pas la base de données de journalisation dans cet article.

Dans notre environnement de laboratoire, nous avons limité la journalisation et la base de données de journalisation dans une instance SQL Server séparée.

Serveur de base de données - Instance par défaut	SQL Server
Processeurs	4 processeurs quadruple cœur 2,4 GHz
Mémoire RAM	32 Go
Système d’exploitation	Windows Server 2008 R2 SP1
Stockage et géométrie	Stockage à connexion directe (DAS) 1 volume système (RAID0, 1 broche, 300 Go) 2 volumes de données de contenu (RAID0, 4 broches, 450 Go chacune) 2 volumes de journalisation de contenu (RAID0, 2 broches, 450 Go chacune) 1 volume de données temporaires (RAID0, 2 broches, 300 Go chacune) 1 volume de journalisation temporaire (RAID0, 2 broches, 300 Go chacune)
Nombre de cartes réseau	1
Vitesse de la carte réseau	1 gigabit
Authentification	Windows NTLM
Version logicielle requise	SQL Server 2008 R2

Topologie

Le diagramme suivant illustre la topologie de notre environnement de laboratoire de test.

Configuration

Le tableau suivant montre les changements de configuration importants que nous avons apportées au serveur de base de données dans notre environnement de laboratoire. Ces modifications de configuration autorisent pour des performances optimales et désactivez les relations entre les paramètres de test et les résultats. Notez que le paramètre MAXDOP est requis pour SharePoint Server 2013. Les autres modifications de configuration s’appliquent à notre environnement de test uniquement et ne peuvent pas affecter votre environnement de production.

Paramètre	Valeur	Remarques
Collection de sites	179 (total dans l’environnement)	Les collections de sites dans notre environnement de test utilisent les paramètres par défaut et l’authentification basée sur les revendications Windows.
Mise en cache BLOB	Activée	La valeur par défaut est Désactivée. Si vous activez la mise en cache BLOB, vous améliorez l’efficacité du serveur en réduisant les appels du serveur de base de données pour les ressources de page statiques susceptibles d’être demandées fréquemment par les navigateurs.
Degré maximal de parallélisme (MAXDOP)	1	Ce paramètre est défini sur l’ou les instances qui contiennent des bases de données de contenu SharePoint Server 2013SQL Server. La valeur par défaut est 0, ce qui permet de SQL Server déterminer le degré maximal de parallélisme. SharePoint Server 2013 requiert MAXDOP à définir à 1 pour les instances de SQL Server qui contiennent des bases de données SharePoint Server 2013. Pour plus d’informations sur la configuration du paramètre MAXDOP pour SQL Server 2008 R2, voir Option Degré maximal de parallélisme. Pour plus d’informations sur la configuration du paramètre MAXDOP pour SQL Server 2012, voir Configurer l’option de configuration du serveur Degré maximal de parallélisme.

Charge de travail

Cette section explique les tests de laboratoire que nous ayons contre SharePoint Server 2013. Les détails de test sont typiques d’un environnement de collaboration de division.

Jeu de données

Le jeu de données que nous avons utilisé pour notre environnement de laboratoire de test est typique d’un environnement de collaboration de division. Ce jeu de données contient des collections de sites, sites, listes, bibliothèques, types de fichiers et tailles de fichiers divers.

Caractéristiques du jeu de données	Valeur
Taille de la base de données (combinée)	174 Go
Taille MDF	154 Go
Taille LDF	20 Go
Taille BLOB	152 Go
Nombre de bases de données de contenu	2
Nombre de collections de sites	179
Nombre d’applications Web	1
Nombre de sites	1,471

Résultats et analyse

Les résultats suivants sont triés en fonction de l’approche de montée en puissance décrite à la section Vue d'ensemble.

Montée en puissance du serveur web

Les sections suivantes décrivent les résultats des tests obtenus lors de la montée en puissance des serveurs web présents dans notre environnement de laboratoire de test.

Méthodologie de test

• Ajouter des serveurs web qui utilisent les mêmes spécifications matérielles et exécuter à nouveau le test sans modifier la batterie de serveurs ni les paramètres de test.

• Mesurer le RPS, la latence et l’utilisation des ressources sur chaque serveur de la batterie de test.

Analyse

Voici ce que nos tests ont révélé :

• L’environnement est monté en puissance jusqu’à dix serveurs web par serveur de base de données. L’augmentation de débit a été relativement linéaire.

• Même jusqu’à la charge maximale testée de dix serveurs Web, l’ajout de serveurs de base de données supplémentaires n’a pas provoqué d’augmentation du débit. De manière générale, le goulot d’étranglement s’est limité aux ressources des serveurs Web.

• La latence moyenne de zone verte a été presque constante sur l’ensemble du test. Le nombre de serveurs web et le débit n’a pas eu d’impact sur la latence de zone verte. Les données de latence de zone rouge indiquent une courbe de tendance attendue. La latence est très élevée avec un seul serveur web. Avec 2 à 8 serveurs web, la courbe reste confortablement dans les critères de la zone rouge.

  Notes

  La latence peut être légèrement affectée lorsque vous déplacez le service de cache distribué des serveurs web d’une batterie de serveurs vers un serveur dédié au cache distribué, en raison du fait que le trafic de cache distribué, qui était auparavant interne pour chaque serveur web, commence à transiter par le réseau. Testez les performances de montée en charge dans votre propre environnement afin de déterminer si cette perte est importante. Notez que cette latence dans notre environnement de test a augmenté modérément lorsque le service de cache distribué a été migré vers un serveur dédié. La latence a baissé à chaque ajout de serveur web car la latence nominale ajoutée a été compensée par la baisse de la charge de mémoire et de traitement sur les serveurs web.
  Pour plus d’informations sur la planification de la capacité du cache distribué, voir Planifier les flux et le service de cache distribué dans SharePoint Server.

• Grâce à l’amélioration des caractéristiques d’utilisation de base de données et de la mise en cache dans SharePoint Server 2013, la charge moyenne sur la couche de base de données du serveur est faible. Nous avons constaté qu’au cours de nos tests il n’était pas nécessaire de faire évoluer les serveurs de base de données.

• Lorsque vous ajoutez des serveurs web virtuels, les gains en performances dépendent en partie des ressources matérielles des hôtes et de l’utilisation des ressources des autres ordinateurs virtuels qui sont exécutés sur le même hôte. Les serveurs virtuels requièrent des stratégies de gestion et de planification supplémentaires propres à la virtualisation.

  Pour plus d’informations sur la planification de capacité et de performances Hyper-V, voir Configuration requise pour la virtualisation Hyper-V pour SharePoint 2013 et Utiliser des configurations recommandées pour les ordinateurs virtuels SharePoint 2013 et l’environnement Hyper-V.

Résultats, graphiques et diagrammes

Dans les graphiques suivants, l’axe des X correspond à la modification du nombre de serveurs web dans la batterie de serveurs. La montée en charge commence par un serveur web virtuel et un serveur de base de données physique (1x1). Le maximum est de 8 serveurs web virtuels, d’un serveur de cache distribué virtuel dédié (ajouté lorsque quatre serveurs web sont utilisés) et d’un serveur de base de données physique (8x1x1).

1. Demandes par seconde (RPS)

Le graphique suivant représente l’impact de la montée en puissance sur la référence RPS.

2. Latence

Le graphique suivant illustre l’impact de la montée en charge sur la latence. Notez que la latence de zone verte reste quasiment plate, mais la latence de zone rouge montre des augmentations comprises dans des limites acceptables.

3. Utilisation de la mémoire et des processeurs des serveurs web

Le graphique suivant illustre l’impact de la montée en charge sur l’utilisation moyenne des processeurs et de la mémoire des serveurs web. Notez que l’utilisation moyenne de la mémoire et que l’utilisation des processeurs de zone verte reste relativement constante lors de l’augmentation du nombre de demandes par seconde.

La tendance d’utilisation des processeurs dans la zone rouge est à la baisse. Cette tendance à la baisse reflète le fait que la demande moyenne du processeur du serveur web à charge maximale décline à mesure que le nombre de serveurs augmente.

4. Opérations d’E/S SQL Server par seconde et utilisation des processeurs

Les graphiques suivants indiquent la variation du nombre moyen d’opérations d’E/S disque (à la fois les totaux et les opérations de lecture/d’écriture) et des valeurs d’utilisation des processeurs avec l’augmentation du nombre de serveurs web. Les compteurs de performances suivants ont été utilisés pour mesurer les valeurs des opérations d’E/S :

• PhysicalDisk : lectures disque/s.

• PhysicalDisk : écritures disque/s.

La moyenne des valeurs de chaque compteur pendant la durée du test est calculée, puis les moyennes obtenues sont cumulées pour générer le nombre total d’opérations d’E/S.

Notez que dans les graphiques de cette section, les opérations d’E/S et l’utilisation des processeurs des serveurs de base de données affichent une chute à 6 serveurs web frontaux, alors que le nombre de demandes par seconde continue d’augmenter. Cette variation est également reflétée dans l’utilisation des processeurs des serveurs web, comme indiqué dans le graphique précédent.

Cela signifie que la montée en charge de la batterie de serveurs a atteint un niveau où la pression maximale sur les ressources des serveurs de la batterie a été atteinte en utilisant la charge et le jeu de données de référence. Une utilisation moyenne moins élevée des ressources des serveurs est nécessaire pour prendre en charge la charge de la batterie de serveurs.

Il est possible de tirer les conclusions suivantes de cette tendance :

• Si la charge du test avait été augmentée au sixième point de charge de serveur web, un nombre plus élevé de demandes par seconde aurait pu être obtenu tout en conservant une courbe plate de l’utilisation des ressources des serveurs.

• Si le nombre de serveurs web avait été davantage augmenté tout en maintenant la même charge de test, le nombre de demandes par seconde aurait continué à augmenter alors que la pression sur les ressources des serveurs aurait continué à baisser.

1. Nombre total d’opérations d’E/S SQL Server

   Le graphique suivant montre l’impact de la montée en charge sur le nombre total d’opérations d’E/S.

   

2. Opérations d’E/S SQL Server réparties en opérations de lecture et d’écriture

   Le graphique suivant illustre l’impact de la montée en puisance sur les opérations d’E/S pour les lectures par seconde et les écritures par seconde.

   

3. Utilisation du processeur SQL Server

   Le graphique suivant illustre l’impact de la montée en puissance sur l’utilisation du processeur SQL Server.

   

See also

Planifier les performances de planification dans Microsoft SharePoint Server 2013
Résultats des tests de performances et de capacité, avec recommandations (SharePoint Server 2013)
Estimer les performances et la capacité requises pour les environnements de collaboration intranet des entreprises (SharePoint Server 2013)