Estimer les performances et la capacité requises pour les environnements sociaux (SharePoint Server 2013)

 

**Sapplique à :**SharePoint Server 2013

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

Résumé : Découvrez comment déterminer le nombre et les types d’ordinateurs nécessaires pour un plan de capacité pour un portail de fonctionnalités sociales et un site Mon site basés sur SharePoint Server 2013.

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

Dans cet article :

• Introduction to this environment

• Glossary

• Overview

• Spécifications

• Résultats et analyse

Introduction à cet environnement

Les entreprises utilisent souvent des SharePoint Server 2013 pour publier mon Site et portails informatiques sociales authentifiés l’accès sur un site intranet. Cet article contient les données de capacité et de performances pour vous aider à planifier le nombre d’ordinateurs à utiliser et les types d’ordinateurs qui sont tenus de publier mon Site et portails d’informatiques sociales dans SharePoint Server 2013.

Conseils supplémentaires explique comment mettre à l’échelle des serveurs dans un SharePoint Server 2013 entreprise Mon Site et une solution de portail informatique sociale. Planification de la capacité informe les décisions concernant le matériel à l’achat et les configurations système qui optimisent votre solution.

Batteries de serveurs individuels SharePoint Server 2013 étant uniques, chaque batterie de serveurs a des exigences différentes qui dépendent du matériel, le comportement de l’utilisateur, la configuration des fonctionnalités installées et de nombreux autres facteurs. Par conséquent, compléter ce guide avec des tests supplémentaires sur votre propre matériel dans votre propre environnement. Si votre conception planifiée et la charge de travail ressemble à l’environnement décrit dans cet article, vous pouvez utiliser cet article pour tirer des conclusions sur la façon de mettre à l’échelle de votre environnement.

Les résultats des tests présents dans cet article ont été générés dans un laboratoire de test, avec une charge de travail, un jeu de données et une architecture qui simulent un environnement de production soumis à des conditions hautement contrôlées. Même si ces tests ont été conçus avec la plus grande attention, un laboratoire de test ne présente jamais les mêmes caractéristiques de performances et ne se comporte jamais de la même manière qu’un environnement de production. Ces résultats ne représentent pas les caractéristiques de performances et de capacité d’une batterie de serveurs de production, mais démontrent 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 la gestion de votre 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, lisez les articles suivants pour vous assurer que vous comprenez les concepts essentiels de la gestion de capacité dans SharePoint Server 2013.

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

• Limitations et frontières logicielles pour SharePoint 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 (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.

  Important

  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

Entité	% 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 %	10K	100K	500K
Nombre de sites Mon site mis en service	100 %	10K	100K	500K
Nombre de profils utilisateur avec des photos de l’utilisateur	50 %	5K	50K	250K
Nombre de profils utilisateur avec des publications	10 %	1K	10K	50K
Nombre d’équipes		1,860	18,600	93K
Nombre d’utilisateurs actifs par jour	10 %	1K	10K	50K
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 Entreprise

• utilisation du client OneDrive Entreprise

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 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 Entreprise	https://msft-my.spoppe.com/personal/<user>/Documents
Accéder à la page des documents suivis	3 %	OneDrive Entreprise	https://msft-my.spoppe.com/personal/<user>/Social/FollowedContent.aspx
Accéder à la page des documents suivis	3 %	OneDrive Entreprise	https://msft-my.spoppe.com/personal/<user>/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 page @mentions	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 sites 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 de client OneDrive Entreprise

Action de l’utilisateur	Pourcentage	Scénario	Fonctionnalité ou URL
Synchronisation initiale de OneDrive Entreprise	0.2%	OneDrive Entreprise	Synchronisation initiale
Synchronisation incrémentielle de OneDrive Entreprise - télécharger un fichier	0.88%	OneDrive Entreprise	Synchronisation incrémentielle
Synchronisation incrémentielle de OneDrive Entreprise - aucune modification	8.1%	OneDrive Entreprise	Synchronisation incrémentielle

Méthodologie de test

Nous avons commencé avec une configuration de batterie minimale SharePoint Server 2013 pour les fonctionnalités sociales. Nous appliqué une charge sociale caractéristique de la batterie de serveurs de test et a augmenté la charge jusqu'à ce que nous avons observé des niveaux de capacité de serveur normal et maximum. Nous avons analysé les goulots d’étranglement au niveau de chacun de ces niveaux de charge et ajouté des machines du rôle surchargé de faire évoluer la configuration de la batterie de serveurs. Cet ajout atténuées les goulots d’étranglement dans chaque cas et fourni une vue des caractéristiques d’évolutivité du serveur pour un groupe de données particulier. Nous avons répété ce processus d’évolution pour les trois tailles de déploiement afin de fournir des synthèses représentatifs des caractéristiques d’évolutivité d’une batterie de SharePoint Server 2013 et des instructions pour 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.

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

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.

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

Rôle	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

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 réussie SharePoint Server 2013 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 de l’utilisation de balises ou de @mention) dans la combinaison de transactions peut faire 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 recommandations de configuration standard SharePoint Server 2013 pour des performances optimales. Considérations importantes spécifiquement les transactions sociales sont les suivantes :

• 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 de SharePoint Server 2013 sociale rend obligatoire pour mettre en service un site personnel pour chaque utilisateur qui souhaite utiliser des fonctionnalités sociales. Planifier la croissance de la création de collections de site personnel au niveau de la base de données de contenu. Pour plus d’informations sur la façon de mettre à l’échelle des collections de sites personnels, consultez Limitations et frontières logicielles pour SharePoint 2013.

See also

Planifier les performances de planification dans Microsoft SharePoint Server 2013

Limitations et frontières logicielles pour SharePoint 2013