Évaluer les exigences de performances et de capacité pour Access Services dans SharePoint Server 2010

S’applique à : SharePoint Server 2010 Enterprise

Dernière rubrique modifiée : 2016-11-30

Cet article fournit des instructions concernant l’empreinte de l’utilisation d’Access Services dans Microsoft SharePoint Server 2010 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

• Dépannage

Caractéristiques de la batterie de serveurs de test

Cette section décrit le jeu de données utilisé lors des tests, les charges de travail placées sur le produit durant la collecte des données de performances, le matériel utilisé lors des tests et la topologie de déploiement de ce matériel.

Jeu de données

La capacité et les performances d’Services d’accès dépendent fortement de la composition des applications hébergées sur le service. La taille des tables et la complexité des requêtes ont souvent l’effet le plus notable sur la capacité et les performances. Les tests ont fait appel à des tailles et des complexités représentatives, mais chaque application et jeu de données est différent. La capacité et les performances dépendent des applications utilisées, de leur complexité spécifique et de la taille des données.

Pour évaluer le profil de capacité, les applications Services d’accès ont été simulées sur une batterie dédiée à Services d’accès (aucun autre test SharePoint n’était en cours d’exécution). La batterie contenait les sites représentatifs suivants :

• 1500 applications Services d’accès ayant un profil de « Petite » taille ; 100 éléments par liste maximum.

• 1500 applications Services d’accès ayant un profil de « Moyenne » taille ; 2000 éléments par liste maximum.

• 1500 applications Services d’accès ayant un profil de « Grande » taille ; 10 000 éléments par liste maximum.

Chaque application est composée de plusieurs listes et les autres listes sont dimensionnées de manière appropriée en fonction de cette liste la plus grande. Services d’accès est capable de gérer plus de 10 000 éléments. Ce chiffre pour le profil « Grande » a été choisi car on s’attendait à ce que les applications plus grandes soient rares.

Les applications ont été distribuées de manière égale parmi les applications suivantes :

• Contacts   Une application de gestion de contacts simple, dominée par une liste unique.

• Projets   Une application de suivi de tâches et de projets simple, dominée par deux listes (projets et tâches associées à chaque projet).

• Commandes   Un système d’entrée de commandes simple, semblable à l’exemple Northwind Traders d’Microsoft Access, mais à une échelle moindre, qui contenaient de nombreuses listes interconnectées (commandes, détails de commandes, factures, détails de factures, bons de commande, détails de bons de commande, et ainsi de suite).

Charge de travail

Pour simuler l’utilisation des applications, des charges de travail ont été créées afin d’effectuer une ou plusieurs des opérations suivantes :

• ouverture de formulaires ;

• pagination parmi des formulaires ;

• filtrage et tri de feuilles de données ;

• mise à jour, suppression et insertion d’enregistrements ;

• publication d’application ;

• affichage de rapports.

Chaque charge de travail inclut un « temps de réflexion » entre les actions utilisateur, allant de 5 à 20 secondes. Cela diffère des autres documents de planification de la capacité SharePoint. Services d’accès est une application avec état ; des curseurs de mémoire et des jeux d’enregistrements ont été conservés entre les interactions utilisateur. Il était important de simuler une session utilisateur complète et non simplement des demandes individuelles. Pour une charge de travail utilisateur unique, il y a une moyenne de deux demandes par seconde.

Le tableau suivant montre les pourcentages utilisés pour déterminer l’application et la taille d’application à utiliser.

Définitions des zones vertes et rouges

Pour chaque configuration, deux tests ont été exécutées afin de déterminer une « zone verte » et une « zone rouge ». La zone verte correspond au débit recommandé pouvant être soutenu. La zone rouge correspond au débit maximal pouvant être toléré durant un court moment, mais qui doit être évité.

La zone verte a été définie comme un point auquel le test exécuté consomme au plus la moitié de la ressource de goulet d’étranglement. Dans le cas présent, celle-ci était %CPU sur l’une des trois couches : serveur Web frontal, serveur d’applications (Access Data Services) ou serveur de bases de données (SQL Server). Tout d’abord, le goulet d’étranglement a été identifié pour une configuration particulière. Si celui-ci était CPU Access Data Services, nous nous sommes assurés que le test de zone verte consommait des ressources CPU sur les ordinateurs Access Data Services dans une plage comprise entre 40 et 50 pour cent.

Pour la zone rouge, on a sélectionné un point auquel le débit maximal était atteint, à savoir une valeur CPU comprise entre 80 et 90 pour cent. Lors de la recherche du goulet d’étranglement, nous avons observé les valeurs de % CPU, utilisation de la mémoire (octets privés), longueur de file d’attente de disque, E/S réseau et autres ressources susceptibles de provoquer un goulet d’étranglement.

Les tests de zones verte et rouge ont été exécutés pendant une heure à une charge utilisateur fixe.

Vos résultats peuvent varier

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. Cette simulation ne constitue qu’une estimation des opérations que des utilisateurs réels pourraient effectuer. Les chiffres présentés ici sont destinés à 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 du système, testez la configuration afin de déterminer si le système prendra en charge les facteurs dans votre environnement.

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. Les configurations de batterie étaient composées de un à quatre serveurs Web frontaux, de un à quatre serveurs d’applications (en cas de présence d’Services d’accès ou Access Data Services) et d’un serveur de bases de données unique exécutant Microsoft SQL Server 2008. En outre, les tests ont été réalisés à l’aide de quatre ordinateurs clients. Tous les ordinateurs serveurs étaient des ordinateurs 64 bits. Tous les ordinateurs clients étaient des ordinateurs 32 bits.

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

Topologie

D’après notre expérience, le processeur sur la couche de serveur d’applications, où Access Data Services s’exécute, est un facteur de limitation important pour le débit. Nous avons varié notre topologie en ajoutant des ordinateurs Access Data Services supplémentaires jusqu’à ce que cela ne constitue plus un goulet d’étranglement, puis nous avons ajouté un serveur Web frontal afin d’obtenir encore davantage de débit.

• 1x1 : un ordinateur serveur Web frontal pour un ordinateur Access Data Services

• 1x2 : un ordinateur serveur Web frontal pour deux ordinateurs Access Data Services

• 1x3 : un ordinateur serveur Web frontal pour trois ordinateurs Access Data Services

• 1x4 : un ordinateur serveur Web frontal pour quatre ordinateurs Access Data Services

• 2x1 : deux ordinateurs serveurs Web frontaux pour un ordinateur Access Data Services

• 2x2 : deux ordinateurs serveurs Web frontaux pour deux ordinateurs Access Data Services

• 2x4 : deux ordinateurs serveurs Web frontaux pour quatre ordinateurs Access Data Services

L’ordinateur exécutant SQL Server est relativement puissant et n’a constitué à aucun moment un goulet d’étranglement (bien qu’il est approché la valeur de saturation CPU lors de notre test 2x4) ; il n’a donc pas fait l’objet de variation dans nos topologies. En fonction des requêtes qui font partie d’une combinaison d’applications du monde réel, on s’attend à ce que le serveur de bases de données (SQL Server) puisse devenir le goulet d’étranglement.

Reporting Services s’exécutait en mode connecté pour tous nos tests, dans la couche de serveur d’applications (Access Data Services).

Résultats des tests

Les tableaux suivants indiquent les résultats des tests d’Services d’accès. Pour chaque groupe de tests, seules certaines variables spécifiques sont modifiées pour indiquer l’impact progressif sur les performances de la batterie de serveurs.

Tous les tests mentionnés dans cet article ont été réalisés en prenant en compte un temps d’attente ou de réflexion. Ceci diffère des résultats de planification de la capacité pour d’autres composants de SharePoint.

Pour plus d’informations sur les goulets d’étranglement d’Services d’accès, voir Goulets d’étranglement courants et leurs causes (éventuellement en anglais) plus loin dans cet article.

Échelle globale

Le tableau et le graphique suivants résument l’impact de l’ajout de serveurs Web frontaux et d’ordinateurs Access Data Services dédiés supplémentaires à la batterie. Ces chiffres de débit s’appliquent spécifiquement aux ordinateurs Access Data Services. Ils ne reflètent pas l’impact sur la batterie dans son ensemble.

Résultats recommandés

Le graphique suivant montre les résultats pour le débit soutenable recommandé.

Comme décrit plus haut dans cet article, l’ajout du quatrième ordinateur Access Data Services fait basculer le goulet d’étranglement vers le serveur Web frontal et l’ajout d’un second serveur Web frontal élimine la contrainte de ressource sur la couche de serveurs Web frontaux. Cela pourrait suggérer que 1x1, 1x2 et 1x3 sont des configurations raisonnables. Toutefois, lorsque le quatrième ordinateur Access Data Services est ajouté, un serveur Web frontal doit également être ajouté. L’évolutivité s’effectuant de manière linéaire (ligne droite entre 1x1 et 1x4), on peut supposer que l’ajout d’un septième ordinateur Access Data Services impliquerait également l’ajout d’un troisième serveur Web frontal, et ainsi de suite, afin de répondre aux besoins de la batterie.

Souvenez-vous que ces résultats sont fondés uniquement sur une charge de travail simulée et qu’un déploiement réel doit être contrôlé afin d’identifier le point auquel des serveurs Web frontaux supplémentaires sont nécessaires pour prendre en charge des ordinateurs Access Data Services supplémentaires. En outre, les serveurs Web frontaux sont dédiés à Services d’accès, alors qu’en réalité ils seront probablement partagés avec d’autres charges de travail SharePoint. Le graphique suivant montre les résultats.

Le graphique suivant indique le temps de réponse à ce niveau de débit. Il est très faible, moins d’¼ de seconde par demande en moyenne.

Ces résultats montrent que l’ordinateur SQL Server ne constituait pas un goulet d’étranglement, car l’ajout d’un second serveur Web frontal a permis d’éliminer la pénurie de ressource et la valeur de CPU de SQL Server était toujours inférieure à 50 pour cent. Cependant, il faut savoir que l’instance de SQL Server est partagée avec d’autres services SharePoint et avec SharePoint lui-même ; l’effet cumulatif risque par conséquent d’augmenter la valeur d’utilisation de CPU et la longueur de file d’attente d’E/S disque jusqu’à un point où ils deviennent réellement un goulet d’étranglement.

Maximum

Le graphique suivant montre les résultats, dans lesquels le débit a été poussé au-delà de ce qui pouvait être soutenu.

Nous observons dans ce graphique que là encore un second serveur Web frontal était nécessaire pour optimiser l’utilité du quatrième ordinateur Access Data Services. Vos propres résultats peuvent de nouveau varier, car ils dépendent fortement des applications et de leurs modèles d’utilisation.

Dans le cas présent, le temps de réponse est allongé car le système global est sous pression. Toutefois, ces niveaux sont de l’ordre d’une seconde et encore acceptables pour la plupart des utilisateurs.

Il peut sembler étrange qu’avec quatre ordinateurs Access Data Services, deux serveurs Web frontaux présentent un temps de réponse plus élevé qu’un seul serveur Web frontal. Ceci est dû au fait que le débit global du système est supérieur avec deux serveurs Web frontaux.

SQL Server ne constitue toujours pas ici un facteur de limitation, car l’ajout du second serveur Web frontal nous a replacés sur une ligne d’évolutivité linéaire. Toutefois, nous atteignons près de 90 pour cent d’utilisation du processeur sur l’instance de SQL Server. Par conséquent, la marge de manœuvre restante est très réduite. Si nous ajoutions un cinquième ordinateur Access Data Services, l’ordinateur SQL Server constituerait probablement un goulet d’étranglement.

Résultats détaillés

Les tableaux suivants indiquent les résultats détaillés pour les configurations recommandées.

Les tableaux suivants indiquent les résultats détaillés pour les configurations maximales.

Recommandations

Cette section fournit des recommandations générales sur les performances et sur la capacité.

La capacité et les performances d’Services d’accès dépendent fortement de la composition des applications hébergées sur le service. La taille des tables et la complexité des requêtes ont souvent l’effet le plus notable. Les tests ont fait appel à des tailles et des complexités représentatives, mais chaque application et jeu de données est différent. Par conséquent, la capacité et les performances dépendent des applications utilisées, de leur complexité spécifique et de la taille des données.

Recommandations relatives au matériel

Services d’accès utilise un matériel standard pour les serveurs Web frontaux et les serveurs d’applications ; aucune condition spéciale n’est requise. Les recommandations générales applicables à SharePoint Server 2010 en matière de vitesse, de mémoire et de nombre de processeurs s’appliquent aux ordinateurs de la couche de serveurs d’applications (Access Data Services).

Topologies avec montée en puissance parallèle et par unité

Pour accroître la capacité et les performances de l’une des topologies de départ, deux options sont possibles. Vous pouvez effectuer une montée en puissance par unité en augmentant la capacité de vos serveurs existants ou une montée en puissance parallèle en ajoutant des serveurs supplémentaires à la topologie. Cette section décrit les caractéristiques de performances générales de plusieurs topologies avec montée en puissance parallèle.

Les exemples de topologies représentent les moyens courants suivants d’effectuer une montée en puissance parallèle d’une topologie pour un scénario Services d’accès :

• Pour pouvoir gérer une charge utilisateur supérieure, vérifiez le processeur des serveurs d’applications Services d’accès existants. Ajoutez des processeurs ou des cœurs (ou les deux) à ces serveurs dans la mesure du possible. Ajoutez des ordinateurs serveurs Services d’accès en cas de besoin, jusqu’à un point auquel le serveur Web frontal devient un goulet d’étranglement ; après cela, ajoutez des serveurs Web frontaux selon les besoins.

• Dans nos tests, la mémoire sur la couche de serveurs Web frontaux et sur la couche de serveurs d’applications (Access Data Services) ne constituait pas un goulet d’étranglement. En fonction de la taille des jeux de résultats, la mémoire pourrait poser un problème. Néanmoins, ceci ne devrait pas être la norme. Effectuez le suivi des octets privés pour le processus w3wp Access Data Services, comme décrit ici.

• Dans nos tests, SQL Server ne constituait pas un goulet d’étranglement. Toutefois, ces tests ont été exécutés de manière isolée par rapport à d’autres services SharePoint Server 2010. Les valeurs de processeur et d’E/S de disque SQL Server doivent être contrôlées et des serveurs ou des piles supplémentaires doivent être ajoutés en cas de besoin.

Paramètres d’Access Services liés aux performances

L’une des façons de contrôler les caractéristiques de performances d’Services d’accès consiste à limiter la taille et la complexité des requêtes qui peuvent être exécutées. Services d’accès fournit un ensemble de seuils configurables afin de contrôler les requêtes. Chacune des requêtes suivantes peut être définie par le biais de l’Administration centrale SharePoint. (Dans la section Gestion des applications, cliquez sur Gérer les applications de service, puis sur Services d’accès.)

En règle générale, la quantité de données à extraire de SharePoint pour exécuter une requête a un impact considérable sur les performances. Ce facteur peut être contrôlé de plusieurs manières. Tout d’abord, les entrées d’une requête peuvent être limitées :

• Sources maximales par requête

• Nombre maximal d’enregistrements par table

Ensuite, la taille résultante d’une requête peut être limitée :

• Nombre maximal de colonnes par requête

• Nombre maximal de lignes par requête

• Autoriser les jointures externes

Outre la taille de la requête (taille des données en entrée et en sortie), la complexité de traitement des données peut être contrôlée de manière à réduire la charge du processeur sur la couche de serveurs d’applications (Access Data Services) :

• Nombre maximal de colonnes calculées par requête

• Nombre maximal de clauses Order by dans la requête

Il est évident que les paramètres précédents affecteront les applications pouvant être exécutées sur le serveur. Par exemple, si une application est écrite avec 40 colonnes de sortie d’une requête et que les paramètres sont inférieurs à ce niveau, l’application génèrera une erreur d’exécution. Il convient d’atteindre un équilibre entre les besoins des utilisateurs et les performances acceptables ; cet équilibre dépendra fortement du genre d’applications Accès qui seront exécutées sur la batterie.

Il est possible de prendre une mesure supplémentaire plus radicale. SharePoint Server 2010 prend en charge un ensemble d’opérations de requête de manière native, qu’Services d’accès augmente de manière à couvrir un ensemble plus étendu de scénarios d’applications. Pour qu’Services d’accès puisse améliorer les requêtes SharePoint, il est possible qu’une grande quantité de données doivent être extraites de la base de données de contenu SharePoint. Au lieu de cela, Services d’accès peut être configuré de façon à gérer uniquement les opérations de requête, qui sont prises en charge de manière native par SharePoint. Ceci permet d’éviter l’extraction de données requise pour les opérations plus complexes :

• Autorise les requêtes non distantes

Optimisations

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 où 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.

Le tableau de la section Dépannage plus loin dans cet article répertorie certains goulets d’étranglement courants et décrit leurs causes et résolutions possibles.

Analyse des performances

Pour déterminer à quel moment vous devez appliquer une montée en puissance parallèle ou par unité à votre système, analysez l’intégrité du système à l’aide de compteurs de performance. En vous appuyant sur les informations indiquées dans les tableaux suivants, déterminez les compteurs de performance à analyser et le processus auquel appliquer ceux-ci :

Serveurs Web frontaux

Le tableau suivant indique les compteurs de performance et les processus à analyser pour les serveurs Web de votre batterie.

Access Data Services

Le tableau suivant montre les compteurs de performance et les processus à analyser pour les serveurs d’applications, ou Accès Data Services (Access Data Services) dans le cas présent, dans votre batterie.

Serveurs de bases de données

Le tableau suivant indique les compteurs de performance et les processus à analyser pour les serveurs de bases de données de votre batterie.

Dépannage

Le tableau suivant répertorie certains goulets d’étranglement courants et décrit leurs causes et les résolutions possibles.