Évaluer les besoins en performances et en capacité pour PerformancePoint Services

S’applique à : SharePoint Server 2010

Dernière rubrique modifiée : 2017-01-18

Cet article décrit l’impact de l’utilisation de PerformancePoint Services sur les topologies exécutant Microsoft SharePoint Server 2010.

Dans cet article :

• Caractéristiques de la batterie de serveurs de test

• Résultats des tests

• Recommandations

Pour obtenir des informations générales sur la planification de capacité et l’exécution qui en résulte pour SharePoint Server 2010, voir Capacity management and sizing for SharePoint Server 2010.

Caractéristiques de la batterie de serveurs de test

Jeu de données

Le jeu de données était constitué d’un portail d’entreprise créé à l’aide de SharePoint Server 2010 et PerformancePoint Services et contenant un seul tableau de bord de taille moyenne. Ce tableau de bord contenait deux filtres liés à une carte de performance, deux graphiques et une grille. Il était basé sur une source de données Microsoft SQL Server 2008 Analysis Services (SSAS) unique utilisant les exemples de bases de données AdventureWorks pour le cube SQL Server 2008 Analysis Services.

Le tableau suivant décrit le type et la taille de chaque élément du tableau de bord.

Le tableau de bord de taille moyenne utilisait le modèle Deux colonnes avec en-tête et les tailles des éléments de tableau de bord étaient configurées pour un dimensionnement automatique ou avaient pour valeur un pourcentage spécifique du tableau de bord. Chaque élément du tableau de bord était affiché avec une hauteur aléatoire et une largeur comprise entre 400 et 500 pixels afin de simuler les différences de taille de fenêtre de navigateur Web. Il est important de modifier la hauteur et la largeur de chaque élément de tableau de bord car le rendu des graphiques dépend de la taille des fenêtres de navigateurs Web.

Scénarios et processus de test

Cette section définit les scénarios de test et traite du processus de test utilisé pour chaque scénario. Vous trouverez des informations détaillées telles que les résultats des tests et les paramètres spécifiques dans les sections Résultats des tests plus loin dans cet article.

Une combinaison de tests unique a été utilisée, constituée des pourcentages de tests démarrés suivants.

Les outils de test de charge de Microsoft Visual Studio 2008 ont été utilisés afin de créer un ensemble de tests Web et de tests de charge simulant des opérations d’utilisateurs (modification de filtres et navigation sur des grilles et des graphiques). Les tests utilisés dans cet article contenait une distribution normales de pauses de 15 secondes, également appelées « temps de réflexion », entre les interactions et un temps de réflexion de 15 secondes entre les itérations de tests. Une charge a été appliquée afin de produire un temps de réponse moyen de deux secondes pour l’affichage d’une carte de performance ou d’un rapport. Le temps de réponse moyen a été mesuré sur une période de 15 minutes après un délai de préchauffage initial de 10 minutes.

Chaque nouvelle itération de test sélectionne un compte d’utilisateur distinct parmi un pool de cinq mille comptes et une adresse IP aléatoire (à l’aide de la commutation IP de Visual Studio) parmi un pool d’environ 2 200 adresses.

La combinaison de tests a été exécutée à deux reprises sur le même tableau de bord de taille moyenne. Lors de la première exécution, l’authentification de source de données a été configurée de façon à utiliser le Compte de service autonome, qui utilise un compte commun pour demander les données. Les résultats des données sont identiques pour plusieurs utilisateurs et PerformancePoint Services peut utiliser la mise en cache afin d’améliorer les performances. Lors de la seconde exécution, l’authentification de source de données a été configurée de façon à utiliser l’identité par utilisateur et le cube SQL Server Analysis Services a été configuré de façon à utiliser la sécurité dynamique. Dans cette configuration, PerformancePoint Services utilise l’identité de l’utilisateur pour demander les données. Les résultats des données pouvant être différents, aucune mise en cache ne peut être partagée par les utilisateurs. Dans certains cas, la mise en cache pour l’identité par utilisateur peut être partagée si la sécurité dynamique Analysis Services n’est pas configurée et que les rôles Analysis Services, auxquels les utilisateurs et groupes Microsoft Windows sont assignés, sont identiques.

Configuration matérielle et topologie

Matériel de laboratoire

Pour fournir un niveau élevé de détails de résultats de tests, plusieurs configurations de batterie de serveurs ont été utilisées lors des tests. Ces configurations comprenaient de un à trois serveurs Web, de un à quatre serveurs d’applications et un serveur de bases de données unique exécutant Microsoft SQL Server 2008. Une installation d’entreprise par défaut de SharePoint Server 2010 a été effectuée.

Le tableau suivant indique le matériel spécifique utilisé lors des tests.

Une fois la batterie étendue avec plusieurs serveurs Web, un système d’équilibrage de la charge matérielle a été utilisé afin d’équilibrer la charge utilisateur sur plusieurs serveurs Web à l’aide de l’affinité d’adresse source. L’affinité d’adresse source enregistre l’adresse IP source des demandes entrantes et l’hôte de service sur lequel leur charge a été équilibrée, et elle dirige toutes les transactions ultérieures vers le même hôte.

Topologie

La topologie de départ était constituée de deux serveurs physiques, l’un agissant comme serveur Web et serveur d’applications, l’autre assumant la fonction de serveur de bases de données. Cette topologie de départ est considérée comme une topologie à deux ordinateurs (ou 2M, c’est-à-dire 2 machines), ou encore comme topologie « 1 par 0 par 1 » (où le nombre de serveurs Web dédiés est indiqué en premier, suivi du nombre de serveurs d’applications dédiés, puis du nombre de serveurs de bases de données).

Les serveurs Web sont également appelés serveurs Web frontaux (ou WFE, Web Front End) plus loin dans ce document. La charge a été appliquée jusqu’à ce que des facteurs de limitation soient rencontrés. En règle général, le facteur de limitation sur le serveur Web ou le serveur d’applications était le processeur. Des ressources ont ensuite été ajoutées afin d’annuler les effets de cette limite. Les facteurs de limitation et les topologies différaient sensiblement selon la configuration de l’authentification de source de données (Compte de service autonome ou identité par utilisateur avec sécurité du cube dynamique).

Résultats des tests

Les résultats des tests contenaient trois mesures importantes pour aider à définir la capacité de PerformancePoint Services.

Avec les topologies comprenant plus de quatre serveurs d’applications, il est probable que le goulet d’étranglement soit le serveur Analysis Services. Analysez le processeur et la durée de requête de votre serveur Analysis Services afin de déterminer s’il est nécessaire de faire monter en puissance Analysis Services avec plusieurs serveurs. Tout prolongement de la durée de requête sur le serveur Analysis Services accroît de manière significative le temps de réponse moyen de PerformancePoint Services au-delà du seuil souhaité (deux secondes).

Les tableaux qui suivent fournissent une synthèse des résultats de tests pour l’authentification de Compte de service autonome et l’authentification par utilisateur lors de l’extension de deux à sept serveurs. Vous trouverez des résultats détaillés incluant des compteurs de performance supplémentaires plus loin dans ce document.

Synthèse de l’authentification de Compte de service autonome

Synthèse de l’authentification par utilisateur

Topologies 2M et 3M

Afin de mieux comprendre le coût matériel par transaction et la courbe de temps de réponse, les tests de charge ont été exécutés avec quatre charges utilisateur d’intensité croissante, jusqu’à la charge utilisateur maximale pour les topologies 2M et 3M.

Authentification de Compte de service autonome

Authentification par utilisateur

Résultats pour la batterie 3M (1x1x1)

Authentification de Compte de service autonome

Authentification par utilisateur

Résultats 4M+ pour l’authentification de Compte de service autonome

À partir de la topologie 4M, une charge a été appliquée afin de produire un temps de réponse moyen de deux secondes pour l’affichage d’une carte de performance ou d’un rapport. Ensuite, un serveur supplémentaire a été ajouté afin d’éliminer le facteur de limitation (toujours le processeur sur le serveur Web ou le serveur d’applications), puis la combinaison de tests a été réexécutée. Cette logique a été répétée jusqu’à atteindre un total de sept serveurs.

Résultats 4M+ pour l’authentification par utilisateur

Les mêmes tests ont été répétés pour une source de données configurée pour l’authentification par utilisateur. Notez que l’ajout d’un serveur d’applications afin de créer une topologie à quatre serveurs d’applications n’a pas augmenté le nombre d’utilisateurs ou de demandes par secondes pouvant être pris en charge par PerformancePoint Services, à cause des délais de requêtes générés par Analysis Services.

Recommandations

Recommandations relatives au matériel

Les compteurs de mémoire et de processeur mentionnés dans les tableaux de tests doivent être utilisés afin de déterminer la configuration matérielle requise pour une installation de PerformancePoint Services. Pour les serveurs Web, PerformancePoint Services utilise la configuration matérielle SharePoint Server 2010 recommandée. Il se peut que la configuration matérielle requise pour les serveurs d’applications doive être modifiée lorsque PerformancePoint Services consomme une grande quantité de mémoire. Cela se produit lorsque des sources de données sont configurées avec l’authentification par utilisateur ou lorsque le serveur d’applications exécute de nombreux tableaux de bord avec de longs délais d’attente de source de données.

Le serveur de bases de données n’est pas devenu un goulet d’étranglement dans les tests et l’utilisation maximale du processeur a atteint une pointe de 31 % avec le tableau de bord authentifié avec le Compte de service autonome 7M. Les définitions de contenu PerformancePoint Services telles que les rapports, cartes de performance et indicateurs de performance clés sont stockées dans des listes SharePoint et mis en cache en mémoire par PerformancePoint Services, ce qui réduit la charge sur le serveur de bases de données.

Consommation de mémoire

PerformancePoint Services peut consommer de grandes quantités de mémoire dans certaines configurations, c’est pourquoi il est important d’analyser l’utilisation de la mémoire du pool d’applications PerformancePoint Services. PerformancePoint Services met en cache plusieurs éléments en mémoire, notamment des résultats de requêtes Analysis Services et d’autres sources de données pendant toute la durée de vie du cache de source de données (par défaut, 10 minutes). Lorsque vous utilisez une source de données configurée pour l’authentification de Compte de service autonome, ces résultats de requête sont stockés une fois et partagés par plusieurs utilisateurs. En revanche, lorsque vous utilisez une source de données configurée pour l’authentification par utilisateur et la sécurité de cube dynamique Analysis Services, les résultats de requête sont stockés une fois par utilisateur par affichage (il s’agit donc d’une combinaison « par filtre ».)

L’API de cache sous-jacente utilisée par PerformancePoint Services est l’API de cache ASP.NET. L’avantage majeur offert par l’utilisation de cette API est le fait qu’ASP.NET gère le cache et supprime les éléments en fonction des limites de mémoire, afin d’éviter les erreurs d’insuffisance de mémoire. Une fois ces limites atteintes, PerformancePoint Services générait tout de même ces affichages, mais les temps de réponse augmentaient de manière significatives durant la brève période durant laquelle ASP.NET supprimait les entrées mises en cache.

Le compteur de performance « Applications ASP.NET \ Suppressions d’API du cache » du pool d’applications hébergeant PerformancePoint Services peut être utilisé afin d’analyser les suppressions du cache ASP.NET qui se produisent suite à une pression sur la mémoire. Si ce compteur est supérieur à zéro, examinez le tableau suivant afin de trouver une solution.

Une source de données configurée de façon à utiliser l’authentification par utilisateur peut partager des résultats de requêtes et des entrées de cache si les ensembles d’appartenances de rôles Analysis Services des utilisateurs sont identiques et si la sécurité de cube dynamique n’est pas configurée. Il s’agit d’une nouvelle fonctionnalité de PerformancePoint Services dans Microsoft SharePoint Server 2010. Par exemple, si l’utilisateur A est dans les rôles 1 et 2, que l’utilisateur B est dans les rôles 1 et 2, et que l’utilisateur C est dans les rôles 1, 2 et 3, seule les utilisateurs A et B partagent des entrées de cache. Si la sécurité de cube dynamique est activée, les utilisateurs A, B et C ne partagent pas d’entrées de cache.

Analysis Services

Lors des tests de PerformancePoint Services avec l’authentification par utilisateur, deux propriétés Analysis Services ont été modifiées afin d’améliorer les performances de débit multi-utilisateur. Le tableau suivant montre les propriétés qui ont été modifiées et indique la nouvelle valeur de chaque propriété.

Ces deux paramètres de mémoire configurent Analysis Services de façon à utiliser le segment Windows plutôt que le segment Analysis Services. Avant de modifier ces propriétés et durant l’ajout de la charge utilisateur, les temps de réponse ont augmenté sensiblement, passant de 0,2 seconde à plus de 30 secondes, tandis que les valeurs de processeurs sur les serveurs d’applications, serveurs Web et serveurs Analysis Services sont restées faibles. Afin de résoudre ce problème, la durée de requête a été recueillie à l’aide de vues de gestion dynamique Analysis Services, ce qui a montré une augmentation des durées de requêtes allant de 10 millisecondes à 5000 millisecondes. Ces résultats ont entraîné une modification des paramètres de mémoire mentionnés ci-dessus.

Il convient de noter que bien que cela ait augmenté sensiblement le débit, d’après l’équipe Analysis Services, la modification de ces paramètres présente un coût faible mais mesurable sur les requêtes d’utilisateur unique.

Avant de modifier des propriétés Analysis Services, consultez le Livre blanc SQL Server 2008 : guide des performances d’Analysis Services (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x40C) (éventuellement en anglais) afin de connaître les meilleures pratiques pour l’amélioration des performances de débit multi-utilisateur.

Goulets d’étranglement courants et leurs causes

Durant les tests de performances, plusieurs goulets d’étranglement courants ont été révélés. Un goulet d’étranglement est une condition dans laquelle la capacité d’un composant spécifique d’une batterie est atteinte, ce qui provoque une stabilisation ou une diminution du débit de la batterie. Si une utilisation élevée du processeur a été rencontrée comme goulet d’étranglement, des serveurs supplémentaires ont été ajoutés afin d’éliminer ce goulet d’étranglement. Le tableau suivant répertorie certains goulets d’étranglement courants et fournit des résolutions possibles en supposant que l’utilisation du processeur était faible et ne constituait pas le goulet d’étranglement.

Analyse des performances

Pour vous aider à déterminer le moment où une montée en puissance parallèle ou par unité du système est nécessaire, utilisez des compteurs de performance afin d’analyser l’intégrité du système. PerformancePoint Services est un service WCF ASP.NET qui peut être analysé à l’aide des mêmes compteurs de performance que tout autre service WCF ASP.NET. Utilisez également les informations fournies dans les tableaux suivants afin d’identifier les compteurs de performance supplémentaires à analyser et les processus auxquels ces compteurs de performance doivent être appliqués.

See Also

Concepts

Planifier PerformancePoint Services (SharePoint Server 2010)