Estimer les performances et la capacité requises pour les environnements sociaux (SharePoint Server 2013)
S’APPLIQUE À :
2013 
2016 2019 Subscription Edition SharePoint dans Microsoft 365
Dans le but de créer un plan de performances et de capacité pour une solution de portail de fonctionnalités sociales et de site Mon Site pour un intranet d'entreprise, cet article contient des informations sur les aspects suivants :
Spécifications de l'environnement de laboratoire, telles que le matériel, la topologie et la configuration de la batterie de serveurs
La charge de travail et le jeu de données de la batterie de serveurs de test qui ont été utilisés pour générer le test de charge
Les analyses et résultats des tests qui démontrent et expliquent les tendances du débit, de la latence et de la demande matérielle sous charge à des points d'échelle spécifiques.
Utilisez les informations contenues dans cet article pour mieux comprendre les concepts suivants :
Caractéristiques du scénario en période de charge normale et maximale
Comment les tendances des performances évoluent lorsque les serveurs de la batterie de serveurs sont montés en charge
Comment évaluer un point de départ approprié pour votre architecture planifiée
Facteurs essentiels à prendre en considération lorsque vous planifiez que les ressources de votre batterie de serveurs devront conserver des niveaux de performances acceptables en période de charge maximale
Introduction à cet environnement
Les entreprises utilisent souvent SharePoint Server 2013 pour publier des portails de fonctionnalités sociales et des sites Mon site auxquels des utilisateurs authentifiés ont accès via un site intranet. Cet article contient des données sur la capacité et les performances qui vous aideront à planifier le nombre et les types d'ordinateurs nécessaires pour les portails de fonctionnalités sociales et les sites Mon site dans SharePoint Server 2013.
Des instructions supplémentaires expliquent comment monter en charge des serveurs dans une solution de portail de fonctionnalités sociales et de sites Mon site SharePoint Server 2013 pour une entreprise. La planification de la capacité permet d'éclairer les décisions concernant le matériel à acheter et les configurations système requises qui optimisent votre solution.
Étant donné que les batteries de serveurs SharePoint Server 2013 individuelles sont uniques, chaque batterie de serveurs a des exigences différentes qui dépendent du matériel, du comportement des utilisateurs, de la configuration des fonctionnalités installées et de nombreux autres facteurs. Par conséquent, vous devez compléter ces instructions en testant à nouveau votre propre matériel dans votre propre environnement. Si la conception et la charge de travail planifiées sont semblables à l'environnement décrit dans cet article, vous pouvez utiliser cet article pour vous aider à comprendre comment faire monter votre environnement en charge.
Les résultats des tests de cet article ont été produits dans un laboratoire de test, à l’aide d’une charge de travail, d’un jeu de données et d’une architecture pour simuler un environnement de production dans des conditions hautement contrôlées. Bien que la conception de ces tests ait fait l’objet d’un grand soin, les caractéristiques de performance d’un laboratoire de test ne sont jamais les mêmes que le comportement d’un environnement de production. Ces résultats de test ne représentent pas les caractéristiques de performances et de capacité d’une batterie de serveurs de production. Au lieu de cela, les résultats des tests illustrent les tendances observées en matière de débit, de latence et de demande matérielle. Utilisez l’analyse des données observées pour vous aider à planifier la capacité et à gérer votre propre batterie de serveurs.
Cet article aborde 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, consultez les articles suivants pour vous assurer que vous maîtrisez les concepts centraux de la gestion de capacité dans SharePoint Server 2013
Dans ces articles, vous trouverez les informations suivantes :
L'approche recommandée en matière de gestion de capacité
Des indications sur la manière d’utiliser efficacement les informations contenues dans cet article
Glossaire
La liste suivante contient les définitions des termes clés présents dans cet article.
RPS: Demandes par seconde. RPS est le nombre de demandes qu’une batterie ou un serveur reçoit en une seconde. C'est une mesure courante de la charge d'un serveur ou d'une batterie de serveurs.
Importante
Notez que les demandes sont différentes des chargements de page. Chaque page contient plusieurs composants et chacun de ces composants crée une ou plusieurs demandes lorsqu'un navigateur charge une page. Par conséquent, un chargement de page crée plusieurs demandes. Les vérifications et les événements d'authentification qui utilisent très peu de ressources ne sont généralement 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 à 0,5 seconde pour au moins 75 % des demandes.
Utilisation moyenne du processeur inférieure à 50 % pour tous les serveurs.
Taux d'échec inférieur à 0,1 %.
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.
Cela correspond aux situations dans lesquelles le serveur peut respecter l'ensemble des critères suivants pendant une durée limitée :
Latence côté serveur inférieure à 1 seconde pour au moins 75 % des demandes.
Utilisation moyenne du processeur de serveur de base de données inférieure à 80 %.
Taux d'échec inférieur à 0,1 %.
Vue d’ensemble
Cette section résume notre approche de montée en charge, la relation entre cet environnement de laboratoire et un environnement d’étude de cas similaire, et notre méthodologie de test.
Approche de montée en charge
Nous vous recommandons de monter en charge les ordinateurs de votre environnement dans l’ordre spécifique que nous avons suivi pour la montée en charge de notre environnement de laboratoire de test. Cette approche vous permettra de trouver la meilleure configuration pour votre charge de travail.
Nous avons divisé les cycles de test de performances en trois catégories de charge de travail. Le paramètre principal qui a déterminé la limite de catégorie est le nombre de profils utilisateur, qui a été défini sur 10 000, 100 000 et 500 000 tests de profil utilisateur. Un autre paramètre était constitué du nombre d'utilisateurs actifs, qui exécutaient des actions liées à l'ensemble des fonctionnalités sociales. À partir du nombre d'utilisateurs ayant un profil et du nombre d'utilisateurs actifs, nous avons exécuté des tests pour simuler une utilisation de l'application qui serait similaire aux déploiements réels. Le tableau suivant représente le jeu de données initial et le nombre d'utilisateurs actifs.
Jeu de données initial
| Entity | % d’utilisateurs avec cette fonctionnalité | Faible (10 000 utilisateurs) | Moyen (100 000 utilisateurs) | Élevé (500 000 utilisateurs) |
|---|---|---|---|---|
| Nombre de profils utilisateur pour les utilisateurs |
100 % |
10 000 |
100 000 |
500 000 |
| Nombre de sites Mon site mis en service |
100 % |
10 000 |
100 000 |
500 000 |
| Nombre de profils utilisateur avec des photos de l'utilisateur |
50 % |
5K |
50 000 |
250 000 |
| Nombre de profils utilisateur avec des publications |
10 % |
1K |
10 000 |
50 000 |
| Nombre d'équipes |
1,860 |
18,600 |
93 Ko |
|
| Nombre d'utilisateurs actifs par jour |
10 % |
1K |
10 000 |
50 000 |
| Nombre d'utilisateurs actifs par heure |
5 % |
500 |
5K |
25K |
Test axé sur les scénarios clés suivants :
Accès à la page Flux d'actualités et autres actions
Page de profil
Accès à la page Flux de sites et autres actions
Synchronisation des flux d'activité d'Outlook Social Connector
Accès à la page OneDrive
Utilisation du client OneDrive
Pour simuler un scénario de déploiement réaliste, tous les tests ont été effectués sur une base de données qui contenait déjà des données. Le jeu de données était un modèle d'une organisation hiérarchisée avec une moyenne de 4 à 6 utilisateurs par équipe, sur 3 ou 4 niveaux. Pour générer ces chiffres, nous avons analysé le trafic à partir d'un site social interne. Le tableau suivant décrit l'ensemble des paramètres que nous avons utilisés pour créer le jeu de données initial.
Modèle de données pour la base de données initiale
| Description d’entité de données | Nombre |
|---|---|
| Nombre moyen d’utilisateurs au sein d’une équipe |
5 |
| Nombre moyen de niveaux par organisation |
4 |
| Nombre d'équipes pour 1 000 utilisateurs |
186 |
| Nombre moyen de collègues qu'un utilisateur suit |
50 |
| Nombre de propriétés de profil utilisateur |
93 |
Le tableau suivant décrit l'ensemble des paramètres en termes d'actions qui entraîneraient le remplissage de données :
Caractéristiques d'utilisation
| Paramètre | Nombre ou pourcentage |
|---|---|
| Pourcentage d’utilisateurs avec 1 à 3 publications |
10 % |
| Nombre moyen de publications par utilisateur |
2 |
| Nombre moyen de réponses par publication |
2 |
| Pourcentage de publications qui sont aimées |
15 % |
| Pourcentage de publications avec des liens |
5 % |
| Pourcentage de publications avec des balises |
12 % |
| Pourcentage de publications avec des mentions d'utilisateurs |
8 % |
| Pourcentage de publications avec une image jointe |
5 % |
Pour créer chacun de nos tests de montée en charge, nous avons appliqué la combinaison d'actions suivante sur le jeu de données et le nombre d'utilisateurs actifs précédents :
Actions READ de l'utilisateur
| Action de l’utilisateur | % d’utilisateurs effectuant cette action | Scénario | Fonctionnalité ou URL |
|---|---|---|---|
| Accéder à la page d’accueil de site Mon Site |
12 % |
Flux d'actualités |
Page Flux d'actualités (http://my/default.aspx) |
| Accéder à la page de profil public de l'utilisateur |
8 % |
Profil |
Page de profil (http://my/person.aspx?accountname=<alias>) |
| Accéder à la page de profil privé de l'utilisateur |
4 % |
Profil |
Page Profil (http://my/person.aspx) |
| Synchronisation automatique du flux d'activités |
32 % |
Outlook Social Connector |
aucun |
| Accéder à la page Personnes que je suis |
3 % |
Liste Suivre des personnes |
http://my/MyPeople.aspx |
| Accéder à la bibliothèque de documents par défaut |
6 % |
OneDrive |
https://msft-my.spoppe.com/personal/<utilisateur>/Documents |
| Accéder à la page des documents suivis |
3 % |
OneDrive |
https://msft-my.spoppe.com/personal/<utilisateur>/Social/FollowedContent.aspx |
| Accéder à la page des documents suivis |
3 % |
OneDrive |
https://msft-my.spoppe.com/personal/<utilisateur>/Social/FollowedContent.aspx |
| Accéder à la page Flux de sites |
8 % |
Flux de sites |
Page Flux de sites (https://<domain>/teams/<site>/newsfeed.aspx_ |
| Afficher toutes les réponses sur un thread |
1 % |
Flux d'actualités |
Page Flux d'actualités (http://my/default.aspx) |
| Afficher le flux Tout le monde |
3 % |
Flux d'actualités |
Page Flux d'actualités (http://my/default.aspx) |
| Afficher plus de publications sur le flux d'actualités |
2 % |
Flux d'actualités |
Page Flux d'actualités (http://my/default.aspx) |
| Afficher la @mentions page |
1 % |
Flux d'actualités |
Page Flux d'actualités (http://my/default.aspx) |
| Afficher le flux d'actualités (Mobile) |
1 % |
Mobile |
Appel mobile REST (Representational State transfert) |
| Afficher le flux d'actualités catégorisé |
3 % |
Mobile |
Appel mobile REST |
Actions WRITE de l'utilisateur
| Action de l’utilisateur | Pourcentage | Scénario | Fonctionnalité ou URL |
|---|---|---|---|
| Créer une publication racine dans le flux |
0.5% |
Flux d'actualités |
Page Flux d'actualités (http://my/default.aspx) |
| Aimer une publication dans le flux |
0.3% |
Flux d'actualités |
Page Flux d'actualités (http://my/default.aspx) |
| Répondre à une publication dans le flux |
0.7% |
Flux d'actualités |
Page Flux d'actualités (http://my/default.aspx) |
| Créer une publication dans le flux avec @mention |
0.1% |
Flux d'actualités |
Page Flux d'actualités (http://my/default.aspx) |
| Créer une publication racine dans le flux de sites |
0.5% |
Flux de sites |
Page Flux de site (https://<domain>/teams/<site>/newsfeed.aspx) |
| Créer une publication dans le flux de site avec @mention |
0.5% |
Flux de sites |
Page Flux de site (https://<domain>/teams/<site>/newsfeed.aspx) |
| Répondre à une publication dans le flux de sites |
0.15% |
Flux de sites |
Page Flux de site (https://<domain>/teams/<site>/newsfeed.aspx) |
| Créer une publication dans le flux avec une balise |
0.05% |
Flux de sites |
Page Flux de site (https://<domain>/teams/<site>/newsfeed.aspx) |
Actions du client OneDrive
| Action de l’utilisateur** | Pourcentage | Scénario | Fonctionnalité ou URL |
|---|---|---|---|
| Synchronisation initiale de OneDrive |
0.2% |
OneDrive |
Synchronisation initiale |
| Synchronisation incrémentielle OneDrive - Télécharger un fichier |
0.88% |
OneDrive |
Synchronisation incrémentielle |
| Synchronisation incrémentielle OneDrive - aucune modification |
8.1% |
OneDrive |
Synchronisation incrémentielle |
Méthodologie de test
Nous avons commencé avec une configuration de batterie de serveurs SharePoint Server 2013 minimale pour les fonctionnalités sociales. Nous avons appliqué une charge sociale caractéristique à la batterie de serveurs de test, puis augmenté la charge jusqu'à observer des niveaux de capacité de serveur normaux et maximaux. Nous avons analysé les goulots d'étranglement à chacun de ces niveaux de charge, puis ajouté des machines du rôle surchargé pour monter en charge la configuration de batterie de serveurs. Cet ajout a éliminé les goulots d'étranglement dans chacun des cas et a fourni un affichage des caractéristiques d'évolutivité du serveur pour un jeu de données particulier. Nous avons répété ce processus de montée en charge pour trois tailles de déploiement afin de fournir des résumés représentatifs des caractéristiques d'évolutivité d'une batterie de serveurs SharePoint Server 2013 et des instructions relatives à la planification de la capacité.
Spécifications
Cette section fournit des informations détaillées sur le matériel, le logiciel, la topologie et la configuration de l’environnement de laboratoire.
Importante
Tous les serveurs web et les serveurs d'applications du laboratoire de test ont été virtualisés à l'aide d'hôtes Hyper-V. Les serveurs de base de données n'ont pas été virtualisés. Les hôtes physiques et les ordinateurs virtuels utilisés sont décrits dans les sections suivantes.
Matériel
Le tableau suivant répertorie les spécifications matérielles des ordinateurs qui ont été utilisés lors de ce test. Les serveurs web frontaux qui ont été ajoutés à la batterie de serveurs pendant plusieurs itérations du test sont également conformes à ces spécifications.
Hôtes Hyper-V
La batterie de serveurs inclut un total de trois hôtes Hyper-V configurés de manière identique, et chaque hôte exécute entre une et quatre machines virtuelles.
| Matériel de l’hôte | Valeur |
|---|---|
|
Processeur(s) |
2 processeurs quadruple cœur 2,27 GHz |
|
Mémoire RAM |
64 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
La batterie de serveurs comprend entre 1 et 8 serveurs web virtuels. Un autre serveur virtuel dédié exécute le service de cache distribué.
Notes
Dans un environnement de production, les serveurs dédiés qui exécutent le service de cache distribué sont généralement déployés dans une configuration hautement disponible. Aux fins des tests, nous n’avons utilisé qu’un seul serveur dédié pour le service de cache distribué car la haute disponibilité n’était pas un facteur déterminant.
| Ordinateur virtuel (matériel) | Serveurs Web |
|---|---|
|
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 |
1 gigabit |
|
Authentification |
Windows NTLM |
|
Type d'équilibrage de la charge |
F5 Big-IP |
|
Services à exécution locale |
Application web Microsoft SharePoint Foundation, courrier électronique entrant Microsoft SharePoint Foundation, service Minuteur de flux de travail Microsoft SharePoint Foundation, service web de métadonnées gérées, service de profil utilisateur |
| Ordinateur virtuel (matériel) | Cache |
|---|---|
|
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 |
1 gigabit |
|
Authentification |
Windows NTLM |
|
Services à exécution locale |
Cache distribué, service Minuteur de flux de travail Microsoft SharePoint Foundation |
| Ordinateur virtuel (matériel) | Composant de requête de recherche |
|---|---|
|
Processeurs |
4 processeurs virtuels |
|
Mémoire RAM |
12 Go |
|
Système d'exploitation |
Windows Server 2008 R2 SP1 |
|
Nombre de cartes réseau |
2 |
|
Vitesse de la carte réseau |
1 gigabit |
|
Authentification |
Windows NTLM |
|
Services à exécution locale |
Application web Microsoft SharePoint Foundation, courrier électronique entrant Microsoft SharePoint Foundation, service Minuteur de flux de travail Microsoft SharePoint Foundation, service de paramètres de site et de requête de recherche, recherche SharePoint Server |
| Ordinateur virtuel (matériel) | Composant d’index de recherche |
|---|---|
|
Processeurs |
4 processeurs virtuels |
|
Mémoire RAM |
12 Go |
|
Système d'exploitation |
Windows Server 2008 R2 SP1 |
|
Nombre de cartes réseau |
2 |
|
Vitesse de la carte réseau |
1 gigabit |
|
Authentification |
Windows NTLM |
|
Services à exécution locale |
Application web Microsoft SharePoint Foundation, courrier électronique entrant Microsoft SharePoint Foundation, service Minuteur de flux de travail Microsoft SharePoint Foundation, recherche SharePoint Server |
Serveurs de base de données
Un serveur de base de données physique exécute l'instance SQL Server par défaut qui dispose des bases de données SharePoint. Cet article n'assure pas le suivi de la base de données de journalisation.
Notes
Si vous activez les rapports d'utilisation, nous vous recommandons de stocker la base de données de journalisation sur un numéro d'unité logique (LUN) distinct. Les déploiements importants et certains déploiements intermédiaires peuvent nécessiter une base de données de journalisation dédiée pour réceptionner la demande de volume élevé d'événements de journalisation du processeur. > Dans cet environnement lab, la journalisation était limitée et la base de données de journalisation était stockée dans une instance distincte de SQL Server.
Serveur de base de données - Instance par défaut
|
Processeurs |
2 processeurs quadruple cœur 3,3 GHz |
|
Mémoire RAM |
32 Go |
|
Système d'exploitation |
Windows Server 2008 R2 SP1 |
|
Stockage et géométrie |
Stockage à connexion directe (DAS) Tableau interne avec disque 6 x 300 Go à 15 000 tours/min Tableau interne avec disque 15 x 450 Go à 15 000 tours/min 50 x données de contenu (RAID10 externe, 2 x 3 piles de 300 Go chacune) 50 x journaux de contenu (RAID10 interne, 2 x 2 piles de 300 Go chacune) 1 x données temporaires (RAID10 interne, 2 x 2 piles de 300 Go chacune) 1 x journal temporaire (RAID10 interne, 2 x 2 piles de 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 tableau suivant illustre la topologie de cet environnement de laboratoire :
Topologie de l'environnement de laboratoire
| Role | Petit déploiement (10 000 utilisateurs) | Déploiement moyen (100 000 utilisateurs) | Vaste déploiement (500 000 utilisateurs) |
|---|---|---|---|
| Serveur Web |
2-4 |
4-8 |
8 |
| Cache |
1 |
1-2 |
3 |
| SQL Server |
1 |
1-2 |
2 |
Processus de test
Importante
Les tests modèlent uniquement une utilisation normale pendant les heures d'ouverture sur un portail de fonctionnalités sociales classique. Nous n’avons pas pris en considération les modifications cycliques du trafic généré par l’utilisateur liées aux cycles jour/nuit. Nous avons testé les travaux du minuteur tels que la synchronisation de profil et l’analyse de la recherche de personnes, qui nécessitent des ressources significatives, indépendamment avec la même charge de travail de test afin de déterminer leur impact. > Les tests se concentrent sur les opérations sociales, telles que les flux d’actualités, l’étiquetage social et la lecture des profils de personnes. La combinaison de tests comprend une petite quantité de trafic de collaboration classique afin de mieux simuler un environnement de production. Nous espérons que ces résultats permettront de concevoir un portail distinct dédié aux sites Mon site et aux fonctionnalités sociales. > La combinaison de tests n’inclut pas le trafic provenant de l’analyse de contenu de recherche. >
Nous avons effectué des tests sur des déploiements de petite, moyenne ou grande taille pour les fonctionnalités sociales. Pour configurer le matériel du serveur, nous avons démarré sur des configurations minimales de la plus petite taille possible, puis nous avons rempli la base de données de test avec le jeu de données, comme décrit dans la section Approche de montée en charge.
Nous avons utilisé Visual Studio Team System (VSTS) pour simuler une charge de travail et appliquer une charge sociale caractéristique, qui détermine tout d'abord une petite charge sur le serveur. Nous avons augmenté cette charge lentement et de manière uniforme, puis nous avons enregistré les mesures de performances sur tous les rôles serveur jusqu'à atteindre un nombre de demandes par seconde maximal. Il s'agissait de l'état où une augmentation de la charge appliquée sur la batterie de serveurs n'engendrait aucune augmentation de la sortie de demandes par seconde transmise, en raison des contraintes de goulot d'étranglement du serveur.
À partir de ces mesures enregistrées, nous avons défini des états de zone verte et de zone rouge, qui représentent les états de charge normale et de charge pleine du serveur de machine virtuelle pour la configuration d'un ordinateur donné. Ensuite, nous avons appliqué une charge stable au niveau des zones verte et rouge dans le but d'analyser les mesures de performances d'état stable pour ces charges. Cela nous a fourni une représentation des performances et de l'intégrité du serveur de machine virtuelle dans ces conditions de charge clés, pour chaque configuration de topologie.
Une fois comprises les caractéristiques de charge rouge et verte, ainsi que la courbe de montée en charge pour chaque topologie, nous avons identifié le goulot d'étranglement de la montée en charge qui limitait le nombre de demandes par seconde. Pour la charge de travail sociale, il s'agissait généralement d'un processeur de serveur web pour petits jeux de données. Pour les jeux de données plus conséquents, nous avons également constaté une pression de mémoire sur les nœuds de cache distribué. Nous avons ajouté des serveurs virtuels du rôle surchargé à la configuration, afin de supprimer les goulots d'étranglement dans chacun des cas étudiés, puis nous avons continué le processus de montée en charge. Nous avons par la suite répété l'analyse des tendances de performances et leur conformité aux définitions des zones rouge et verte, pour chaque taille de configuration jusqu'à atteindre la configuration requise pour une taille de déploiement spécifique.
Une fois comprise la taille de chaque déploiement, nous avons reconfiguré la batterie de serveurs de test de la plus petite à la plus grande configuration, nous avons rempli le jeu de données, comme décrit dans la section Approche de montée en charge, puis nous avons effectué à nouveau le cycle de processus d’analyse/montée en charge et mesuré les caractéristiques de montée en charge de chaque taille de jeu de données.
Résultats et analyses
Cette section présente les résultats mesurés pour les trois tailles de déploiement. Plus spécifiquement, elle explique comment la montée en charge de la batterie de serveurs par l'ajout de serveurs web affecte les demandes par seconde de zone verte et rouge, la latence et l'utilisation moyenne du processeur.
Les tendances suivantes ont été cohérentes sur les trois tailles de déploiement :
Le nombre de demandes par seconde des zones rouge et verte augmente de manière linéaire avec le nombre de serveurs web virtuels.
Pour toutes les configurations testées, le principal goulot d'étranglement était le processeur du serveur web.
Pour la zone rouge, la latence croît légèrement lorsque nous ajoutons des serveurs web et que nous augmentons la charge. Cela est dû à la pression ajoutée sur SQL Server et le service de cache distribué (qui est en cours d'exécution sur tous les serveurs web de la batterie de serveurs de test).
En outre, l'utilisation moyenne du processeur sur SQL Server et le service de cache distribué augmentent au même rythme que le nombre de serveurs web. Cela est dû à la charge de mise en cache supplémentaire sur SQL Server et le service de cache distribué.
La latence de la zone verte reste relativement stable tandis que le nombre de serveurs web augmente. C’est pourquoi les serveurs web ne sont pas surchargés sur les niveaux de charge de la zone verte.
Résultats d’une petite montée en charge
Le graphique suivant illustre comment l’augmentation du nombre de serveurs web affecte le nombre de demandes par seconde pour les zones verte et rouge.
Le graphique suivant illustre comment l'augmentation du nombre de serveurs web affecte la latence pour les niveaux de charge des zones verte et rouge.
Le graphique suivant illustre comment l'augmentation du nombre de serveurs web affecte l'utilisation moyenne du processeur pour les niveaux de charge des zones verte et rouge.
Résultats d’une montée en charge moyenne
Le graphique suivant illustre comment l’augmentation du nombre de serveurs web affecte le nombre de demandes par seconde pour les zones verte et rouge.
Le graphique suivant illustre comment l'augmentation du nombre de serveurs web affecte la latence pour les niveaux de charge des zones verte et rouge.
Le graphique suivant illustre comment l'augmentation du nombre de serveurs web affecte l'utilisation moyenne du processeur pour les niveaux de charge des zones verte et rouge.
Résultats d’une montée en charge élevée
Le graphique suivant illustre comment l’augmentation du nombre de serveurs web affecte le nombre de demandes par seconde pour les zones verte et rouge.
Le graphique suivant illustre comment l'augmentation du nombre de serveurs web affecte la latence pour les niveaux de charge des zones verte et rouge.
Le graphique suivant illustre comment l'augmentation du nombre de serveurs web affecte l'utilisation moyenne du processeur pour les niveaux de charge des zones verte et rouge.
Lorsque le nombre de serveurs web augmente, les événements suivants se produisent :
L'utilisation moyenne du processeur augmente pour SQL Server et les nœuds de cache distribué en raison de la charge ajoutée sur ces ressources partagées.
L'utilisation moyenne du processeur de serveur web en zone rouge diminue légèrement en raison du léger décalage du goulot d'étranglement vers SQL Server et les ordinateurs de cache distribué.
L'utilisation moyenne du processeur de serveur web en zone verte reste constante, car les serveurs sont maintenus à des niveaux de charge recommandés.
Recommandations
Un déploiement social de SharePoint Server 2013 réussi en termes de performances dépend des facteurs suivants :
Le nombre d'utilisateurs actifs que vous souhaitez prendre en charge
La combinaison de transactions attendue pour les opérations de lecture et d'écriture
La manière dont la charge est distribuée sur les serveurs de la batterie de serveurs
Le nombre d'utilisateurs actifs attendu est un facteur clé pour déterminer le nombre de serveurs à prévoir dans la topologie. Le nombre d'utilisateurs actifs détermine également la composition de l'hébergement des différents services qui doivent être activés pour le scénario de collaboration sociale sur les serveurs.
Bien que nos tests aient utilisé un jeu de données classique et appliqué la complexité de charge à prendre en considération dans un vrai déploiement de clients, chaque déploiement est unique. Vos efforts de planification de la capacité doivent tenir compte des caractéristiques d'utilisation attendues, de la configuration des fonctionnalités et de la disponibilité des ressources matérielles. Certains facteurs peuvent significativement modifier ou avoir une incidence sur les besoins en capacité, comme les facteurs suivants :
Un modèle d'utilisation accrue de la messagerie électronique peut faire augmenter la charge générée par Outlook Social Connector.
Une augmentation significative du pourcentage d’actions d’écriture (par exemple, une augmentation du balisage ou @mention) de la combinaison de transactions peut augmenter la charge sur le serveur de base de données).
Vous pouvez ajouter ou supprimer des serveurs web afin d'équilibrer la charge du processeur entre les serveurs web, SQL Server et les nœuds de cache distribué.
Suivez attentivement les conseils de configuration standard de SharePoint Server 2013 pour obtenir des performances optimales. Les éléments particulièrement importants à prendre en compte pour les transactions sociales sont les suivants :
Disques physiques séparés pour la base de données de profils - En raison du risque de forte utilisation du disque des transactions sociales sur la base de données de profils, nous vous conseillons de conserver votre base de données de profils sur son propre jeu de disques physiques sur le serveur qui exécute SQL Server.
Configuration requise de la mémoire pour l'application de service de profil utilisateur - L'application de service de profil utilisateur se trouve sur les serveurs web frontaux et repose fortement sur son cache interne. Assurez-vous que les serveurs web frontaux disposent d'une mémoire vive suffisante pour mettre en cache plusieurs demandes de données. La mémoire vive minimale recommandée est de 12 Go par serveur web frontal.
Configuration requise de la mémoire pour les serveurs de cache distribué - Les fonctionnalités sociales, de microblog en particulier, dépendent fortement d'un stockage de cache distribué robuste et suffisant. Des situations de faible mémoire sur ces ordinateurs peuvent dégrader la capacité de la batterie de serveurs SharePoint alors que ce cache est à nouveau en cours de remplissage. Par conséquent, nous vous conseillons de configurer des serveurs qui hébergent le cache distribué de sorte qu'ils utilisent au moins 12 Go de mémoire vive, et d'effectuer une montée en charge lorsque nécessaire, en fonction du nombre total d'utilisateurs dans le déploiement.
Le déploiement social de SharePoint Server 2013 rend obligatoire la mise en service d'un site personnel pour chaque utilisateur souhaitant utiliser des fonctionnalités sociales. Planifiez la croissance de la création de collections de sites personnels au niveau de la base de données de contenu. Pour plus d'informations sur la montée en charge des collections de sites, consultez Limitations et frontières logicielles pour SharePoint 2013.
Voir aussi
Concepts
Planification des performances dans SharePoint Server 2013