É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.
Notes
Il convient de noter que les chiffres spécifiques relatifs à la capacité et aux performances présentés dans cet article diffèreront des chiffres d’un environnement du monde réel. Les chiffres présentés ici sont destinées à fournir un point de départ pour la conception d’un environnement à l’échelle appropriée. Une fois que vous avez terminé la conception initiale de votre système, testez la configuration pour déterminer si votre système prendra en charge les facteurs dans votre environnement.
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.
Nom | Description | Taille |
---|---|---|
Filtre un |
Filtre de sélection de membre |
7 membres de dimension |
Filtre deux |
Filtre de sélection de membre |
20 membres de dimension |
Carte de performance |
Carte de performance |
15 lignes de membres de dimension par 4 colonnes (2 indicateurs de performance clés) |
Graphique un |
Graphique en courbes |
3 séries par 12 colonnes |
Graphique deux |
Graphique à barres empilées |
37 séries par 3 colonnes |
Grille |
Grille analytique |
5 lignes par 3 colonnes |
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.
Nom du test | Description du test |
---|---|
Afficher un tableau de bord et modifier de manière aléatoire l’un des deux filtres à cinq reprises, avec une pause de 15 secondes entre les interactions. |
|
Afficher un tableau de bord, sélectionner un graphique et le développer et le réduire à cinq reprises, avec une pause de 15 secondes entre les interactions. |
|
Afficher un tableau de bord, sélectionner une grille et la développer et la réduire à cinq reprises, avec une pause de 15 secondes entre les interactions. |
|
Une combinaison de tests unique a été utilisée, constituée des pourcentages de tests démarrés suivants.
Nom du test | Combinaison de tests |
---|---|
Afficher un tableau de bord et modifier de manière aléatoire l’un des deux filtres à cinq reprises. |
80 % |
Afficher un tableau de bord, sélectionner un graphique et le développer et le réduire à cinq reprises. |
10 % |
Afficher un tableau de bord, sélectionner une grille et la développer et la réduire à cinq reprises. |
10 % |
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.
Serveur Web | Serveur d’applications | Ordinateur exécutant SQL Server | Ordinateur exécutant Analysis Services | |
---|---|---|---|---|
Processeur(s) |
2px4c @ 2,66 GHz |
2px4c @ 2,66 GHz |
2px4c @ 2,66 GHz |
4px6c @ 2,4 GHz |
RAM |
16 Go |
32 Go |
16 Go |
64 Go |
Système d’exploitation |
Windows Server 2008 R2 Enterprise |
Windows Server 2008 R2 Enterprise |
Windows Server 2008 R2 Enterprise |
Windows Server 2008 R2 Enterprise |
Carte réseau |
1x1 gigabit |
1x1 gigabit |
1x1 gigabit |
1x1 gigabit |
Authentification |
NTLM et Kerberos |
NTLM et Kerberos |
NTLM et Kerberos |
NTLM et Kerberos |
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.
Mesure | Description |
---|---|
Nombre d’utilisateurs |
Nombre total d’utilisateurs signalé par Visual Studio. |
Demandes par seconde |
Nombre total de demandes par seconde signalé par Visual Studio, y compris les demandes de fichiers statiques tels que les images et feuilles de style. |
Affichages par seconde |
Nombre total d’affichages pouvant être effectués par PerformancePoint Services. Un affichage représente tout filtre, carte de performance, grille ou graphique affiché par PerformancePoint Services ou toute demande Web envoyée à l’URL de service de rendu qui contient RenderWebPartContent ou CreateReportHtml. Pour en savoir plus sur CreateReportHtml et RenderWebPartContent, voir la Spécification du protocole RenderingService PerformancePoint Services (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=200609&clcid=0x40C) (éventuellement en anglais). Les journaux IIS peuvent être analysés à la recherche de ces demandes, afin d’aider à planifier la capacité de PerformancePoint Services. Par ailleurs, l’utilisation de cette mesure génère un chiffre qui dépend beaucoup moins de la composition du tableau de bord. Un tableau de bord contenant deux affichages peut être comparé à un tableau de bord en contenant 10. |
Conseil
Lorsque vous utilisez une source de données configurée de façon à utiliser l’authentification de Compte de service autonome, la règle relative au rapport des serveurs dédiés est de un serveur Web pour deux serveurs d’applications exécutant PerformancePoint Services.
Conseil
Lorsque vous utilisez une source de données configurée de façon à utiliser l’authentification par utilisateur, la règle relative au rapport des serveurs dédiés est de un serveur Web pour au moins quatre serveurs d’applications exécutant 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
Topologie (WFE x APP x SQL) | Utilisateurs | Demandes par seconde | Affichages par seconde |
---|---|---|---|
2M (1x0x1) |
360 |
83 |
50 |
3M (1x1x1) |
540 |
127 |
75 |
4M (1x2x1) |
840 |
196 |
117 |
5M (1x3x1) |
950 |
215 |
129 |
6M (2x3x1) |
1 250 |
292 |
175 |
7M (2x4x1) |
1 500 |
346 |
205 |
Synthèse de l’authentification par utilisateur
Topologie (WFE x APP x SQL) | Utilisateurs | Demandes par seconde | Affichages par seconde |
---|---|---|---|
2M (1x0x1) |
200 |
47 |
27 |
3M (1x1x1) |
240 |
56 |
33 |
4M (1x2x1) |
300 |
67 |
40 |
5M (1x3x1) |
325 |
74 |
44 |
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
Nombre d’utilisateurs | 50 | 150 | 250 | 360 |
---|---|---|---|---|
Moyenne de processeurs WFE/APP |
19,20 % |
57,70 % |
94,00 % |
96,70 % |
Demandes par seconde |
18 |
53 |
83 |
83 |
Affichages par seconde |
10,73 |
31,72 |
49,27 |
49,67 |
Temps de réponse moyen (sec) |
0,12 |
0,15 |
0,38 |
2 |
Authentification par utilisateur
Nombre d’utilisateurs | 50 | 100 | 150 | 200 |
---|---|---|---|---|
Moyenne de processeurs WFE/APP |
30,80 % |
61,30 % |
86,50 % |
93,30 % |
Demandes par seconde |
17 |
32 |
43 |
47 |
Affichages par seconde |
10,3 |
19,32 |
26,04 |
27,75 |
Temps de réponse moyen (sec) |
0,28 |
0,45 |
0,81 |
2 |
Résultats pour la batterie 3M (1x1x1)
Authentification de Compte de service autonome
Nombre d’utilisateurs | 100 | 250 | 400 | 540 |
---|---|---|---|---|
Demandes par seconde |
36 |
87 |
124 |
127 |
Affichages par seconde |
21 |
52 |
74 |
75 |
Temps de réponse moyen (sec) |
0,12 |
0,18 |
0,65 |
2 |
Moyenne de processeurs WFE |
11 % |
28 % |
43 % |
46 % |
Octets privés WFE max du processus de travail W3WP Internet Information Services (IIS) SharePoint Server. |
0,7 Go |
1,4 Go |
2,0 Go |
2,4 Go |
Moyenne de processeurs APP |
25 % |
62 % |
94 % |
95 % |
Octets privés APP max de W3WP PerformancePoint Services |
5,9 Go |
10,8 Go |
14,1 Go |
14,6 Go |
Authentification par utilisateur
Nombre d’utilisateurs | 50 | 120 | 180 | 240 |
---|---|---|---|---|
Demandes par seconde |
17 |
39 |
52 |
56 |
Affichages par seconde |
10 |
23 |
31 |
33 |
Temps de réponse moyen (sec) |
0,28 |
0,48 |
0,91 |
2 |
Moyenne de processeurs WFE |
5 % |
12 % |
17 % |
19 % |
Octets privés WFE max de W3WP SharePoint Server |
0,78 Go |
1,3 Go |
1,6 Go |
1,9 Go |
Moyenne de processeurs APP |
25 % |
57 % |
81 % |
81 % |
Octets privés APP max de W3WP PerformancePoint Services |
19 Go |
20,1 Go |
20,5 Go |
20,9 Go |
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.
4M (1x2x1) | 5M (1x3x1) | 6M (2x3x1) | 7M (2x4x1) | |
---|---|---|---|---|
Nombre d’utilisateurs |
840 |
950 |
1250 |
1500 |
Demandes par seconde |
196 |
216 |
292 |
346 |
Affichages par seconde |
117 |
131 |
175 |
206 |
Moyenne de processeurs WFE |
77 % |
63 % |
54 % |
73 % |
Octets privés WFE max de W3WP SharePoint Server |
2,1 Go |
1,7 Go |
2,1 Go |
2,0 Go |
Moyenne de processeurs APP |
83 % |
94 % |
88 % |
80 % |
Octets privés APP max de W3WP PerformancePoint Services |
16 Go |
12 Go |
15 Go |
15 Go |
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.
3M (1x1x1) | 4M (1x2x1) | 5M (1x3x1) | 6M (1x4x1) | |
---|---|---|---|---|
User count |
240 |
300 |
325 |
325 |
Demandes par seconde |
56 |
67 |
74 |
74 |
Affichages par seconde |
33 |
40 |
44 |
45 |
Moyenne de processeurs WFE |
19 % |
24 % |
26 % |
12 % |
Octets privés WFE max de W3WP SharePoint Server |
2,1 Go |
1,9 Go |
1,9 Go |
1,5 Go |
Moyenne de processeurs APP |
89 % |
68 % |
53 % |
53 % |
Octets privés APP max de W3WP PerformancePoint Services |
20 Go |
20 Go |
20 Go |
20 Go |
Processeur Analysis Services |
17 % |
44 % |
57 % |
68 % |
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.
Problème | Solution |
---|---|
L’utilisation du processeur de serveur d’applications est faible et d’autres services s’exécutent sur le serveur d’applications |
Ajouter davantage de mémoire physique ou limiter la mémoire du cache ASP.NET. |
L’utilisation du processeur de serveur d’applications est faible et seul PerformancePoint Services s’exécute sur le serveur d’applications. |
Si cela est acceptable, configurer les paramètres du cache ASP.NET de sorte que celui-ci utilise davantage de mémoire, ou ajouter de la mémoire. |
L’utilisation du processeur de serveur d’applications est élevée. |
Ajouter un autre serveur d’applications. |
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é.
Propriété Analysis Services | Valeur |
---|---|
Mémoire \ HeapTypeForObjects |
0 |
Mémoire \ MemoryHeapType |
2 |
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.
Goulet d’étranglement possible | Cause et élément à analyser | Résolution |
---|---|---|
Performance du segment mémoire Analysis Services |
Par défaut, Analysis Services utilise son propre segment mémoire plutôt que le segment Windows, ce qui procure de médiocres performances de débit multi-utilisateur. Examinez les durées de requêtes Analysis Services à l’aide de vues de gestion dynamique afin de déterminer si les durées de requêtes augmentent avec la charge utilisateur et si l’utilisation du processeur par Analysis Services est faible. |
Modifier Analysis Services de façon à utiliser le segment Windows. Pour obtenir des instructions, voir la section « Analysis Services » plus haut dans cet article et 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). |
Threads de requêtes et de traitement Analysis Services |
Par défaut, Analysis Services limite le nombre de threads de requêtes et de traitement pour les requêtes. Les requêtes de longue durée et les charges utilisateur élevées pourraient utiliser tous les threads disponibles. Analysez les threads inactifs et les compteurs de performance de file d’attente de travaux dans la catégorie MSAS 2008 :Threads. |
Augmenter le nombre de threads accessibles aux requêtes et aux processus. Pour obtenir des instructions, voir la section « Analysis Services » du 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). |
Mémoire des serveurs d’applications |
PerformancePoint Services met en cache les résultats des requêtes Analysis Services et aux sources de données pendant toute la durée de vie du cache de source de données. Ces éléments peuvent consommer une grande quantité de mémoire. Analysez le compteur de performance Applications ASP.NET \ Suppressions d’API du cache du pool d’applications PerformancePoint Services afin de déterminer si des suppressions du cache sont forcées par ASP.NET à cause d’une insuffisance de mémoire. |
Ajouter de la mémoire ou augmenter les limites de mémoire cache ASP.NET par défaut. Pour une discussion supplémentaire, voir la section Consommation de mémoire plus haut dans ce document. Voir également l’article intitulé Paramètres d’éléments de cache ASP.NET (https://go.microsoft.com/fwlink/?linkid=200610&clcid=0x40C) et le billet de blog de Thomas Marquardt Historique des limites de mémoire cache ASP.NET (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=200611&clcid=0x40C) (éventuellement en anglais). |
Paramètres de limitation WCF |
PerformancePoint Services est implémenté en tant que service WCF. WCF limite le nombre maximal d’appels simultanés en guise de comportement de limitation de service. Bien que les requêtes de longue durée puissent atteindre ce goulet d’étranglement, cela est assez rare. Analysez les appels de compteur de performance WCF / Modèle de service non traités pour PerformancePoint Services et comparez ce chiffre au nombre maximal actuel d’appels simultanés. |
Si nécessaire, modifier le comportement de limitation WCF (Windows Communication Foundation). Voir les comportement de limitation de service WCF (https://go.microsoft.com/fwlink/?linkid=200612&clcid=0x40C) et le billet de blog de Wenlong Dong sur la limitation des requêtes WCF et l’évolutivité des serveurs (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=200613&clcid=0x40C) (éventuellement en anglais). |
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.
Compteur de performance | Instance de compteur | Remarques |
---|---|---|
Applications ASP.NET / Suppressions d’API du cache |
Pool d’applications PerformancePoint Services |
Si la valeur est supérieure à zéro, examinez la « Consommation de mémoire ». |
MSAS 2008 :Threads / imitation des requêtes WCF et l’évolutivité des serveurs |
S/O |
Si la valeur est égale à zéro, consultez la section « Analysis Services » du 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). |
MSAS 2008 :Threads / Longueur de la file d’attente des travaux du pool de requêtes |
S/O |
Si la valeur est supérieure à zéro, consultez la section « Analysis Services » du 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). |
MSAS 2008 :Threads / Threads inactifs du pool de traitement |
S/O |
Si la valeur est supérieure à zéro, consultez la section « Analysis Services » du 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). |
MSAS 2008 :Threads / Longueur de la file d’attente des travaux du pool de traitement |
S/O |
Si la valeur est supérieure à zéro, consultez la section « Analysis Services » du Guide des performances d’Analysis Services (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=165486&clcid=0x40C) (éventuellement en anglais). |
WCF CountersServiceModelService 3.0.0.0(*)\Appels non traités |
Instance de service PerformancePoint |
Si la valeur est supérieure à zéro, voir Limitation des requêtes WCF et évolutivité des serveurs (éventuellement en anglais) (https://go.microsoft.com/fwlink/?linkid=200613&clcid=0x40C) (éventuellement en anglais). |
See Also
Concepts
Planifier PerformancePoint Services (SharePoint Server 2010)