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

 

**Sapplique à :**SharePoint Server 2013

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

Résumé : Utilisez les résultats de test et les recommandations de cet article pour évaluer les exigences en matière de performances et de capacité pour une solution de collaboration intranet d’entreprise pour SharePoint Server 2013.

Cet article contient des conseils sur les performances et la planification des capacités pour une solution de collaboration intranet enterprise basé 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.

Dans cet article :

  • Introduction à cet environnement

  • Glossaire

  • Vue d'ensemble

  • Spécifications

  • Résultats et analyse

Introduction à cet environnement

Cet article fournit des conseils sur la façon de faire évoluer les serveurs de la solution de collaboration d’un intranet d’entreprise SharePoint Server 2013. Planification de la capacité informe les décisions concernant le matériel à l’achat et les configurations système qui optimisent votre solution.

Les SharePoint Server 2013 de batteries de serveurs uniques, et 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 qui apparaissent 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 reproduisent 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 en matériel et fournissent une analyse des données observées capables de vous aider à prendre des décisions concernant la planification de 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 charge des serveurs Web

  • Performances du serveur web sur des serveurs physiques et virtuels, la latence et débit de comparaison entre SharePoint Server 2010 et SharePoint Server 2013

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.

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écifiques que vous rencontrerez 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.

    Notez que 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 et les événements d’authentification qui utilisent très peu de ressources ne sont pas comptabilisés dans le calcul RPS.

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

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

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

    • L’utilisation moyenne du processeur est 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.

    Cela correspond aux situations dans lesquelles le serveur peut respecter l’ensemble des critères suivants pendant une durée limitée :

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

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

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

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

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

  • AxBxC (notation du graphique) : 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, voir Architecture des fichiers et des groupes de fichiers.

Vue d’ensemble

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

Approche de montée en 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 :

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

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

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

  4. Nous avons fait monter en charge d’autres serveurs Web jusqu’au maximum pour l’étendue du test.

  5. Nous avons effectué des tests supplémentaires 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 partie d’aucun cluster car la redondance n’était pas nécessaire pour la finalité de ces tests.

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

Important

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 de l’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, à savoir le service du minuteur SharePoint, le service de suivi, Word Automation Services, Excel Services et le service de code en mode 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 possède les bases de données SharePoint. La base de données de journalisation n’est pas abordée 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 de laboratoire, la journalisation était restreinte 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.

This graph shows the lab topology for performance and capacity testing of the enterprise intranet collaboration scenario.

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’ou les instances qui contiennent des bases de données de contenu SharePoint Server 2013SQL Server. La valeur par défaut est 0, ce qui permet de SQL Server déterminer le degré maximal de parallélisme. SharePoint Server 2013 requiert MAXDOP à définir à 1 pour les instances de SQL Server qui contiennent des bases de données SharePoint Server 2013.

Pour plus d’informations sur la configuration du paramètre MAXDOP pour SQL Server 2008 R2, voir Option Degré maximal de parallélisme.

Pour plus d’informations sur la configuration du paramètre MAXDOP pour SQL Server 2012, voir Configurer l’option de configuration du serveur Degré maximal de parallélisme.

Charge de travail

Cette section explique les tests de laboratoire qui sont exécutés par rapport à SharePoint Server 2013. Les détails des tests sont typiques d’un environnement de collaboration d’entreprise.

This graphic displays the breakdown of the performance test workload into operation categories.

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.

Montée en charge 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’à la charge maximale testée de dix serveurs Web, l’ajout de serveurs de base de données supplémentaires n’a pas provoqué d’augmentation du débit. De manière générale, le goulot d’étranglement s’est limité aux ressources des serveurs Web.

  • La latence moyenne de zone verte a été presque constante sur l’ensemble du test. Le nombre de serveurs Web et le débit n’a pas eu d’impact sur la latence de zone verte. Les données de latence de zone rouge indiquent une courbe de tendance attendue. La latence est très élevée avec un seul serveur Web. Avec 2 à 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 de serveurs vers un serveur dédié au cache distribué, en raison du fait que le trafic de cache distribué, qui était auparavant interne pour chaque serveur Web, commence à transiter par le réseau. Testez les performances de montée en charge dans votre propre environnement afin de déterminer si cette perte est importante. Notez que cette latence dans notre environnement de test a augmenté modérément lorsque le service de cache distribué a été migré vers un serveur dédié. La latence a baissé à chaque ajout de serveur Web car la latence nominale ajoutée a été compensée par la baisse de la charge de mémoire et de traitement sur les serveurs Web.
    Pour plus d’informations sur la planification de la capacité du cache distribué, voir Planifier les flux et le service de cache distribué dans SharePoint Server.

  • Lorsque les tests de performances a été effectuée pour SharePoint Server 2010, le serveur de base de données est devenu un goulot d’étranglement au débit maximal à l’aide de quatre serveurs web. Grâce à l’amélioration des caractéristiques d’utilisation de base de données et de la mise en cache dans SharePoint Server 2013, la charge moyenne sur la couche du serveur de base de données est considérablement inférieure dans SharePoint Server 2010, et il n’était pas nécessaire de faire évoluer les serveurs de base de données lors des tests.

    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 la planification de capacité et de performances Hyper-V, voir Configuration requise pour la virtualisation Hyper-V pour SharePoint 2013 et Utiliser des configurations recommandées pour les ordinateurs virtuels SharePoint 2013 et l’environnement Hyper-V.

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 charge sur la référence RPS.

This graph shows the RPS baseline for both Green and Red zones.

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.

This graph shows the relationship between RPS and latency.

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.

This graph shows the relationship between RPS and utilization of web server processor and memory.

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.

Important

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.

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

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

    This graph shows the relationship between RPS and SQL Server total IOPs.

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

    Le graphique suivant illustre l’impact de la montée en 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.

    This graph shows the relationship between RPS and SQL Server IOPs, broken down into read and write operations.

  3. Utilisation du processeur SQL Server

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

    This graph shows the relationship between RPS and SQL Server processor utilization.

Comparaison entre SharePoint Server 2013 et SharePoint Server 2010

Cette section fournit des informations sur la performance de cette charge de travail varie entre SharePoint Server 2013 et SharePoint Server 2010.

Charge de travail

Pour comparer des SharePoint Server 2013 avec SharePoint Server 2010, nous avons utilisé une combinaison de test différent de celui indiqué dans la section spécifications . Cela était nécessaire dans la mesure où certaines fonctionnalités de SharePoint Server 2013 (comme le Service de Cache distribué) et les 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 :

  1. Nous avons créé un environnement SharePoint Server 2010.

  2. Nous avons testé l’environnement SharePoint Server 2010 en utilisant la charge de travail indiquée plus haut dans cette section.

  3. Nous avons mis à niveau les bases de données de contenu vers SharePoint Server 2013 sans modifier les clients consommant de l’environnement.

Cet environnement mis à niveau a été ensuite testé à nouveau sur les serveurs de mise à niveau qui hébergent des SharePoint Server 2013 en utilisant la même combinaison de tests, qui inclut les seules opérations de 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’avez pas modifié le groupe de données après la mise à niveau de base de données de contenu pour les essais de SharePoint Server 2013.

  • La combinaison de tests pour SharePoint Server 2010 exclus nouveau SharePoint Server 2013-opérations spécifiques et semblable de la solution de collaboration d’intranet qui a été testée et décrit plus haut dans cet article.

L’objectif des tests était pour appliquer des charges similaires contre les SharePoint Server 2013 et les SharePoint Server 2010 de batteries de serveurs à l’aide de la même charge de travail et le même groupe de données, puis afficher les différences de consommation de ressources de serveur, la latence et le débit. Les objectifs et les méthodologies de test est différent entre les tests du serveur web physiques et virtuels :

  • L’objectif du test de serveur physique était pour comparer le mode d’exécution de batteries de SharePoint Server 2013 et SharePoint Server 2010 lorsqu’il est étendu sous charge. Les serveurs web de ce test étaient à l’échelle de deux à cinq serveurs web.

  • L’objectif du test de serveur virtuel a été à comparer comment SharePoint Server 2013 et SharePoint Server 2010 de batteries avec quatre serveurs web effectuées au niveau de la Zone de rouge et de vert charges d’utilisateurs. Aucun test horizontale du serveur web ont été réalisés.

Analyse

  • En général, SharePoint Server 2013 effectuée mieux SharePoint Server 2010 lorsqu’il est étendu à cinq serveurs web, mais les résultats SharePoint Server 2010 ont été mieux à deux serveurs web. Le test sur la batterie de serveurs de mise à niveau SharePoint Server 2013 impliquent des optimisations de post-mise à niveau ou non bénéficier de SharePoint Server 2013 des améliorations de performances, tels que le Service de Cache distribué ou Gestionnaire de demande. résultats du test de SharePoint Server 2013, par conséquent, diffèrent considérablement de résultats dans un environnement réel.

  • La relation entre les tendances des données dans les graphiques de cette section montrent comment le modèle de gestion des ressources SharePoint Server 2013 hiérarchise l’utilisation des ressources du processeur sur les e/s de disque.

  • Zone de vert, SharePoint Server 2013 surpasse SharePoint Server 2010 à cinq serveurs web, avec plus de 10 % amélioration de RPS et temps de latence réduits légèrement. Toutefois, pour deux serveurs web, SharePoint Server 2013 donne RPS inférieur et une légère amélioration dans le temps de latence sur SharePoint Server 2010.

  • Au niveau de la Zone rouge SharePoint Server 2013 atteint environ 12 % un débit plus élevé par rapport à SharePoint Server 2010, à cinq serveurs web. Au niveau de deux serveurs web, le débit de SharePoint Server 2010 a été supérieure à 30 % environ. SharePoint Server 2013 a montré une amélioration modérée dans le temps de latence sur SharePoint Server 2010 à cinq serveurs web.

  • Test de serveur web virtuel, les résultats à la fois SharePoint Server 2013 et SharePoint Server 2010 sont similaires au vert Zone. SharePoint Server 2013 indique une amélioration significative sur SharePoint Server 2010 de débit et de latence au niveau de la Zone de rouge.

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

  1. Nombre de demandes par seconde et latence

    Le graphique suivant montre la différence de débit et la latence entre SharePoint Server 2013 et SharePoint Server 2010 avec les deux et cinq serveurs web physique à Zone de vert. SharePoint Server 2010 a RPS supérieur à deux serveurs web et de latence plus élevée. À cinq serveurs web, SharePoint Server 2013 affiche qu'ont augmenté RPS et temps de latence réduits.

    This graph compares Green Zone RPS and latency between SharePoint Server 2013 and SharePoint Server 2010.

    Le graphique suivant montre l’utilisation du processeur avec deux et cinq serveurs web physique à la Zone du rouge à la différence de serveur web. SharePoint Server 2013 surpasse SharePoint Server 2010 dans RPS et temps de latence à 5 serveurs web, mais pas sur les deux serveurs web.

    This graph compares Red Zone RPS and latency between SharePoint Server 2013 and SharePoint Server 2010.

  2. Nombre de demandes par seconde et utilisation des ressources serveur

    Le graphique suivant montre la différence entre les serveurs web et de base de données pour l’utilisation du processeur avec deux et cinq serveurs de web physique au moment du chargement de la Zone de vert. Notez que SharePoint Server 2013 permet d’obtenir un débit supérieur à cinq serveurs web plus efficacement en tirant parti des ressources disponibles du serveur.

    This graph compares Green Zone web server processor utilization between SharePoint Server 2013 and SharePoint Server 2010.

    Le graphique suivant montre la différence entre les serveurs web et de base de données pour l’utilisation du processeur avec deux et cinq serveurs de web physique au moment du chargement de la Zone de rouge. À nouveau, SharePoint Server 2013 permet d’obtenir un débit plus élevé sur cinq serveurs web, mais pas sur les deux serveurs web.

    This graph compares Red Zone web server processor utilization between SharePoint Server 2013 and SharePoint Server 2010.

  3. Demandes par seconde et opérations d’E/S

    Le graphique suivant montre la différence entre les e/s avec deux et cinq serveurs physiques web à la Zone de vert. Notez que, au niveau de la Zone de vert, SharePoint Server 2013SharePoint Server 2016 e/s augmente entre deux et cinq serveurs de web, tandis que SharePoint Server 2010 les e/s réduit. Dans le même temps, le taux de croissance SharePoint Server 2013 RPS est sensiblement plus élevée que dans SharePoint Server 2010. Cette différence de tendances montre comment SharePoint Server 2013 gère les ressources de serveur différemment dans une batterie de serveurs plus grande pour obtenir un débit plus élevé.

    This graph compares Green Zone IOPs between SharePoint Server 2013 and SharePoint Server 2010.

    Le graphique suivant montre la différence entre les e/s avec deux et cinq serveurs de web physique au moment du chargement de la Zone de rouge. Lorsque ces résultats sont résolus dans le graphique de la Zone de rouge dans RPS antérieures et section de l’utilisation des ressources de serveur, vous pouvez observer que le modèle de gestion des ressources SharePoint Server 2013 hiérarchise l’utilisation des ressources du processeur sur les IOPs de disque SQL Server.

    This graph compares Red Zone IOPs between SharePoint Server 2013 and SharePoint Server 2010.

  4. 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 montre la différence entre le débit et latence avec quatre serveurs web virtuels. Au moment du chargement de la Zone de vert, les résultats à la fois SharePoint Server 2013 et SharePoint Server 2010 sont similaires, tandis que SharePoint Server 2013 indique une amélioration significative sur les SharePoint Server 2010 débit et de latence au niveau de la Zone de rouge.

    This graph compares virtual server RPS and latency between SharePoint Server 2013 and SharePoint Server 2010.

    Le graphique suivant montre la différence de la base de données e/s avec quatre serveurs web virtuels. SharePoint Server 2013 indique la que charge d’une amélioration significative dans la seconde Zone de rouge et vert de la base de données.

    This graph compares virtual server IOPs between SharePoint Server 2013 and SharePoint Server 2010.

See also

Planifier les performances de planification dans Microsoft SharePoint Server 2013
Résultats des tests de performances et de capacité, avec recommandations (SharePoint Server 2013)