Estimer les performances et la capacité requises pour les environnements de collaboration intranet des entreprises (SharePoint Server 2013)
S’APPLIQUE À :
2013 
2016 2019 Subscription Edition SharePoint dans Microsoft 365
Cet article contient des instructions sur la planification des performances et de la capacité pour une solution de collaboration intranet d'entreprise basée sur SharePoint Server 2013. Il comprend les éléments suivants :
Les spécifications d'environnement de laboratoire, telles que le matériel, la topologie de batterie de serveurs et la configuration
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.
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 les facteurs importants à prendre en compte lorsque vous planifiez les ressources dont votre batterie de serveurs aura besoin pour maintenir des niveaux de performances acceptables en charge maximale.
Introduction à cet environnement
Cet article fournit des instructions sur la montée en charge des serveurs dans une solution de collaboration intranet d'entreprise SharePoint Server 2013. La planification de la capacité permet d'éclairer les décisions concernant le matériel à acheter et les configurations système qui optimisent votre solution.
Les batteries de serveurs SharePoint Server 2013 individuelles sont uniques et 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 bien d'autres facteurs. Par conséquent, complétez ces conseils avec d’autres tests sur 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 de test qui apparaissent dans 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 émulent 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, et fournissent une analyse des données observées qui peuvent vous aider à prendre des décisions sur la façon de planifier la capacité et de 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 charge des serveurs Web
Comparaison entre le débit, la latence et les performances des serveurs Web de SharePoint Server 2010 et SharePoint Server 2013 sur des serveurs physiques et des ordinateurs virtuels
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
Gestion et dimensionnement de la capacité pour SharePoint Server 2013
Limitations et frontières logicielles pour SharePoint Server 2016
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
Les définitions des termes utilisés dans cet article
Glossaire
Voici quelques termes spécialisés que vous rencontrerez dans cet article.
RPS: Demandes par seconde, ou 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.
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. Par conséquent, un chargement de page crée plusieurs demandes. En règle générale, les vérifications d’authentification et les événements qui utilisent des ressources insignifiantes ne sont pas comptabilisés dans les mesures 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
Étant donné qu'aucune analyse de recherche active n'est en cours d'exécution dans cet environnement de laboratoire, 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.
Le taux d’échec est 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) : il s'agit du nombre de serveurs Web, du nombre de serveurs d'applications et du 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, consultez 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 charge
Cette section décrit l’approche que nous avons adoptée pour faire monter en charge cet environnement de laboratoire. Cette approche va vous permettre de trouver la meilleure configuration pour votre charge de travail :
Nous avons fait monter en charge 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 mis à l’échelle davantage de serveurs web au maximum pour l’étendue des tests.
Nous avons effectué d’autres tests pour comparer les caractéristiques de performances de SharePoint Server 2013 et SharePoint Server 2010.
Remarques sur la méthodologie et les tests
Étant donné que cet article fournit 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.
Notes
Nous vous recommandons d'intégrer ces éléments dans les environnements de production.
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 pas partie d’un cluster, car la redondance n’était pas nécessaire pour les besoins de ces tests.
L’analyse de recherche n’était pas en cours d’exécution pendant les tests. Il peut s’exécuter 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 normalement pendant les tests.
Spécifications
Cette section fournit des détails sur le matériel, les logiciels, la topologie et la configuration de l’environnement de laboratoire.
Matériel
Les sections suivantes décrivent le matériel qui a été utilisé dans cet environnement de laboratoire.
Importante
Notez que tous les serveurs Web et d'applications dans le 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 ci-dessous.
Hôtes Hyper-V
Au total, six hôtes Hyper-V configurés de la même manière ont été utilisés pour les tests. Chaque hôte exécute un ou deux ordinateurs virtuels.
| Matériel hôte | Valeur |
|---|---|
|
Processeur(s) |
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
La batterie de serveurs comprend entre 1 et 10 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) | WFE1-10 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écution locale |
WFE 1-10 : Services fédérés de base. Cela inclut les éléments suivants : Service du minuteur SharePoint, Service de trace, Word Automation Services, Excel Services et Service de code en bac à sable Microsoft SharePoint Foundation. DC1 : service de cache distribué. |
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. La base de données de journalisation n’est pas suivie dans cet article.
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 une demande de volume de journalisation importante 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 | SPSQL |
|---|---|
|
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 de 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 cet environnement de laboratoire.
Configuration
Pour obtenir des performances de test optimales et des relations claires entre les paramètres et les résultats des tests, d'importantes modifications de configuration ont été apportées à cet environnement de laboratoire :
| Paramètre | Valeur | Commentaires |
|---|---|---|
|
Collection de sites |
179 |
Les collections de sites dans l'environnement de test utilisent les paramètres par défaut et l'authentification basée sur les revendications Windows. |
|
Mise en cache BLOB |
Sur |
La valeur par défaut est Désactivé. 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. |
|
Degré maximal de parallélisme (MAXDOP) |
1 |
Ce paramètre est défini sur l'instance ou les instances SQL Server qui contiennent les bases de données de contenu SharePoint Server 2013. La valeur par défaut est 0, ce qui permet à SQL Server de déterminer le degré maximal de parallélisme. SharePoint Server 2013 exige que MAXDOP soit défini sur 1 pour les instances 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 décrit les tests de laboratoire exécutés sur SharePoint Server 2013. Les détails de ces tests sont propres aux environnements de collaboration d'entreprise.
Jeu de données
Dans cet article, le jeu de données pour l'environnement de laboratoire, qui représente un environnement de collaboration d'entreprise classique, contient plusieurs collections de sites, sites, listes, bibliothèques, types de fichier et tailles.
| 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 analyses
Les résultats suivants sont triés en fonction de l’approche de montée en charge décrite à la section Vue d’ensemble de cet article.
Scale-out du serveur web
Cette section décrit les résultats des tests obtenus lors de la montée en charge des serveurs Web présents dans cet environnement de laboratoire.
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 nombre de demandes par seconde, 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 charge jusqu'à dix serveurs Web par serveur de base de données. L'augmentation de débit a été principalement linéaire.
Même jusqu’à l’échelle maximale testée de dix serveurs web, l’ajout de serveurs de base de données supplémentaires n’a pas augmenté le débit. Le goulot d’étranglement était limité aux ressources du serveur 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’ont pas affecté la latence de la zone verte. Les données de latence de zone rouge indiquent une courbe de tendance attendue. La latence est élevée sur un serveur web unique. Avec 2 à 10 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 vers un serveur dédié au cache distribué. Cela peut se produire parce que le trafic du cache distribué, qui était auparavant interne à chaque serveur web, commence à traverser le réseau. Testez les performances de scale-out dans votre propre environnement pour déterminer si ce compromis est significatif. Notez que la latence dans notre environnement de test a légèrement augmenté lorsque le service de cache distribué a été migré vers un serveur dédié. La latence a diminué avec chaque serveur web ajouté, car la latence ajoutée nominale a été décalée par la diminution de la charge de traitement et de mémoire 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.
Lorsque les tests de performances ont été menés pour SharePoint Server 2010, le serveur de base de données est devenu un goulot d'étranglement au débit maximal avec quatre serveurs Web. En raison des améliorations apportées aux caractéristiques de mise en cache et d’utilisation de la base de données dans SharePoint Server 2013, la charge moyenne sur la couche serveur de base de données est inférieure à celle de SharePoint Server 2010 et il n’était pas nécessaire d’effectuer un scale-out des serveurs de base de données pendant le test.
Pour plus d'informations sur les résultats des tests de SharePoint Server 2010 pour ce scénario, voir la page concernant l'étude de laboratoire sur l'environnement de collaboration intranet d'entreprise (SharePoint Server 2010)
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. La planification de capacité pour les serveurs virtuels requiert des stratégies de gestion et de planification supplémentaires propres à la virtualisation.
Pour plus d’informations sur les performances et la planification de la capacité Hyper-V, voir Configuration requise pour la virtualisation Hyper-V pour SharePoint 2013 et Utiliser les configurations de bonnes pratiques pour les machines virtuelles SharePoint 2013 et l’environnement Hyper-V.
Notes
Les conclusions tirées dans cette section sont propres au matériel qui compose l'environnement. L'environnement peut avoir atteint le même débit en utilisant plus de serveurs hôtes Hyper-V moins puissants ou des serveurs hôtes Hyper-V moins nombreux mais plus puissants. Une augmentation des ressources matérielles sur le serveur de base de données n'aura pas d'impact significatif sur les résultats.
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 10 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 (10x1x1).
Notes
Les graphiques de cette section représentent les valeurs moyennes pour chaque point de données pendant la durée du test. Tous les graphiques ont pour référence le nombre de demandes par seconde pour les zones rouge et verte afin de pouvoir indiquer la relation entre le nombre de demandes par seconde et des facteurs tels que la latence, l'utilisation des ressources serveur et l'utilisation du disque SQL Server.
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 principalement plate, alors que la latence de zone rouge montre des variations modérées 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 des processeurs de zone verte reste plutôt constante lors de l'augmentation du nombre de demandes par seconde, alors que l'utilisation moyenne de la mémoire croît légèrement.
L'utilisation des processeurs de zone rouge a tendance à baisser, ce qui reflète le fait que, à la charge maximale, plus le nombre de serveurs est élevé, plus la demande moyenne du processeur des serveurs Web baisse.
4. Opération 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.
Notes
Les données sur l'utilisation de la mémoire SQL Server n'étaient pas disponibles et ne figurent pas sur le graphique.
Importante
Ces résultats de tests sur les opérations d'E/S ne sont pas représentatifs d'un environnement de production car notre jeu de données était bien plus petit que celui d'une batterie de serveurs de production. Il est donc possible qu'un pourcentage plus important des données ait été mis en cache sur les serveurs Web par rapport à ce qui aurait été possible dans un environnement de production. Les résultats des opérations d'E/S dans cette section sont donc des moyennes calculées en fonction des données de test disponibles et devraient être inférieurs aux opérations d'E/S dans un environnement de production. Les tests complets de votre propre batterie de serveurs dans un environnement pilote peuvent générer des résultats différents.
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 à deux reprises : à 9 et à 10 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 neuviè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.
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.
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 charge sur les opérations d'E/S, réparties en opérations de lecture par seconde et en opérations d'écriture par seconde.
Utilisation du processeur SQL Server
Le graphique suivant illustre l'impact de la montée en puissance sur l'utilisation du processeur SQL Server.
Comparaison entre SharePoint Server 2013 et SharePoint Server 2010.
Cette section fournit des informations sur la variation des performances pour cette charge de travail entre SharePoint Server 2013 et SharePoint Server 2010.
Charge de travail
Pour comparer SharePoint Server 2013 et SharePoint Server 2010, nous avons utilisé une combinaison de tests différente de celle indiquée à la section Spécifications. Cela était nécessaire, car certaines fonctionnalités de SharePoint Server 2013 (telles que le service de cache distribué) et certaines opérations n’étaient pas disponibles dans SharePoint Server 2010.
Méthodologie de test
Pour tester les performances dans les deux environnements, nous avons utilisé la méthodologie suivante :
Nous avons créé un environnement SharePoint Server 2010.
Nous avons testé l'environnement SharePoint Server 2010 en utilisant la charge de travail indiquée plus haut dans cette section.
Nous avons mis à niveau les bases de données de contenu vers SharePoint Server 2013 sans modifier les clients qui utilisaient l'environnement.
Cet environnement mis à niveau a ensuite été testé à nouveau sur les serveurs mis à niveau qui hébergent SharePoint Server 2013 à l'aide de la même combinaison de tests, qui comprend uniquement les opérations SharePoint Server 2010.
Nous avons testé deux environnements pour les comparer. Un environnement utilisait des serveurs physiques et l'autre utilisait des ordinateurs virtuels pour exécuter les serveurs Web sur un hôte Hyper-V. Dans les deux cas, le serveur de base de données était exécuté sur un serveur physique.
Nous n’avons pas modifié le jeu de données après la mise à niveau de la base de données de contenu pour les tests SharePoint Server 2013.
La combinaison de tests pour SharePoint Server 2010 ne comprenait pas les nouvelles opérations propres à SharePoint Server 2013 et ressemblait à la solution de collaboration intranet d'entreprise testée et décrite plus haut dans cet article.
L'objectif des tests était d'appliquer des charges similaires aux deux batteries de serveurs SharePoint Server 2013 et SharePoint Server 2010 en utilisant la même charge de travail et le même jeu de données, puis de montrer les différences de débit, de latence et d'utilisation des ressources serveur. Les méthodologies et les objectifs des tests étaient différents selon qu'il s'agissait de tests réalisés avec des serveurs Web physiques et virtuels :
L'objectif des tests sur les serveurs physiques était de comparer les performances des batteries de serveurs SharePoint Server 2013 et SharePoint Server 2010 lors de leur montée en puissance sous charge. Les serveurs Web de ce test ont fait l'objet d'une montée en puissance de deux à cinq serveurs Web.
L'objectif des tests sur les serveurs virtuels était de comparer les performances des batteries de serveurs SharePoint Server 2013 et SharePoint Server 2010 avec quatre serveurs Web aux charges utilisateur de zone rouge et de zone verte. Aucun test de montée en charge de serveur Web n'a été mené.
Analyse
En général, les performances de SharePoint Server 2013 étaient meilleures que celles de SharePoint Server 2010 lorsque la batterie était étendue à cinq serveurs Web, mais les résultats de SharePoint Server 2010 étaient meilleurs avec deux serveurs Web. Les tests sur la batterie de serveurs SharePoint Server 2013 mise à niveau n’impliquent pas d’optimisations post-mise à niveau ni de tirer parti des améliorations des performances de SharePoint Server 2013 telles que le service de cache distribué ou le gestionnaire de demandes. Les résultats des tests SharePoint Server 2013 étaient par conséquent sensiblement différents de ceux pouvant être obtenus dans un environnement réel.
La relation entre les tendances des données dans les graphiques de cette section montre que le modèle de gestion des ressources SharePoint Server 2013 hiérarchise en priorité l'utilisation des ressources du processeur par rapport aux opérations d'E/S disque.
En zone verte, SharePoint Server 2013 affiche de meilleures performances que SharePoint Server 2010 avec cinq serveurs Web, avec une amélioration de plus de 10 % du nombre de demandes par seconde et une latence légèrement plus faible. Toutefois, avec deux serveurs Web, SharePoint Server 2013 génère moins de demandes par seconde et affiche une latence légèrement plus faible que SharePoint Server 2010.
En zone rouge, SharePoint Server 2013 affiche un débit plus élevé de près de 12 % par rapport à celui de SharePoint Server 2010 avec cinq serveurs Web. Avec deux serveurs Web, le débit de SharePoint Server 2010 était environ 30 % plus élevé. SharePoint Server 2013 a affiché une latence légèrement plus faible que SharePoint Server 2010 avec cinq serveurs Web.
Lors des tests avec des serveurs Web virtuels, les résultats en zone verte pour SharePoint Server 2013 et SharePoint Server 2010 sont semblables. En zone rouge, SharePoint Server 2013 affiche une nette amélioration par rapport à SharePoint Server 2010 au niveau du débit et de la latence.
Résultats, graphiques et diagrammes
Les tests qui ont généré les résultats visibles dans les graphiques de cette section ont été effectués sur des serveurs Web physiques et virtuels comme indiqué. Dans tous les tests, un seul serveur de base de données physique exécutant SQL Server 2008 R2 avec SP1 a été utilisé.
Nombre de demandes par seconde et latence
Le graphique suivant affiche la différence de débit et de latence entre SharePoint Server 2013 et SharePoint Server 2010 avec deux et cinq serveurs Web physiques en zone verte. SharePoint Server 2010 présente un nombre de demandes par seconde plus élevé et une latence également plus élevée avec deux serveurs Web. Avec cinq serveurs Web, pour SharePoint Server 2013, le nombre de demandes par seconde augmente et la latence baisse.
Le graphique suivant représente la différence entre l'utilisation du processeur des serveurs Web avec deux et cinq serveurs Web physiques en zone rouge. SharePoint Server 2013 affiche de meilleures performances que SharePoint Server 2010 au niveau de la latence et du nombre de demandes par seconde avec cinq serveurs Web, mais ce n'est pas le cas avec deux serveurs Web.
Nombre de demandes par seconde et utilisation des ressources serveur
Le graphique suivant représente la différence entre l'utilisation du processeur des serveurs Web et de base de données avec deux et cinq serveurs Web physiques en charge de zone verte. Notez que SharePoint Server 2013 affiche un débit plus élevé avec cinq serveurs Web en tirant parti des ressources serveur disponibles plus efficacement.
Le graphique suivant représente la différence entre l'utilisation du processeur des serveurs Web et de base de données avec deux et cinq serveurs Web physiques en charge de zone rouge. Là encore, SharePoint Server 2013 affiche un débit plus élevé avec cinq serveurs Web en tirant parti des ressources serveur disponibles plus efficacement.
Demandes par seconde et opérations d'E/S
Le graphique suivant représente la différence du nombre d'opérations d'E/S avec deux et cinq serveurs Web physiques en zone verte. Notez que dans zone verte, les E/S par seconde SharePoint Server 2013SharePoint Server 2016 augmentent entre deux et cinq serveurs web, tandis que Les E/S par seconde SharePoint Server 2010 diminuent. Cependant, le taux d'augmentation du nombre de demandes par seconde de SharePoint Server 2013 est sensiblement plus élevé que pour SharePoint Server 2010. Cette différence de tendances indique que SharePoint Server 2013 gère les ressources serveur différemment dans une batterie de serveurs plus importante pour améliorer le débit.
Le graphique suivant montre la différence entre le nombre d'opérations d'E/S par seconde avec deux et cinq serveurs Web physiques en charge de zone rouge. Lorsque ces résultats sont comparés avec ceux du graphique de zone rouge figurant à la section précédente sur l'utilisation des ressources serveur et le nombre de demandes par seconde, vous pouvez observer que le modèle de gestion des ressources de SharePoint Server 2013 hiérarchise en priorité l'utilisation des ressources de processeur par rapport aux opérations d'E/S disque SQL Server.
Nombre de demandes par seconde, latence et nombre d'opérations d'E/S des serveurs Web virtuels
Des tests de comparaison des serveurs Web virtuels ont été menés sur 4 serveurs Web virtuels et physiques et un serveur de base de données physique.
Le graphique suivant affiche la différence entre le débit et la latence avec quatre serveurs Web virtuels. En charge de zone verte, les résultats de SharePoint Server 2013 et SharePoint Server 2010 sont semblables, alors que SharePoint Server 2013 affiche une nette amélioration par rapport à SharePoint Server 2010 au niveau du débit et de la latence en zone rouge.
Le graphique suivant affiche la différence entre le nombre d'opérations d'E/S de base de données avec quatre serveurs Web. SharePoint Server 2013 affiche une nette amélioration des performances des opérations d'E/S en charge de zones verte et rouge.
Voir aussi
Concepts
Planification des performances dans SharePoint Server 2013
Résultats des tests de performances et de capacité, avec recommandations (SharePoint Server 2013)