Évaluer la planification des performances et de la capacité des flux de travail dans SharePoint Server 2010

S’applique à : SharePoint Server 2010

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

Cet article sur la planification des performances et de la capacité fournit des conseils sur l’impact de l’utilisation de flux de travail sur les topologies qui exécutent Microsoft SharePoint Server 2010.

Pour des informations générales sur la planification de la capacité pour SharePoint Server 2010, voir Gestion de la performance et de la capacité (SharePoint Server 2010).

Sommaire

• Caractéristiques de la batterie de serveurs de test

• Résultats des tests

• Recommandations

• Résolution des problèmes

Caractéristiques de la batterie de serveurs de test

Les sections suivantes décrivent les caractéristiques de la batterie de serveurs de test :

• Jeu de données

• Charge de travail

• Configuration matérielle, paramètres et topologie

Jeu de données

Dans le cadre des évaluations, la plupart des tests ont été exécutés sur un site d’équipe par défaut appartenant à la même collection de sites dans la batterie de serveurs. Les tests de démarrage manuel consistaient à démarrer les flux de travail en utilisant une liste de 8 000 éléments.

Charge de travail

Les opérations de test réalisées pour ce scénario permettent d’évaluer la façon dont différentes configurations de batterie de serveurs réagissent aux modifications apportées aux variables suivantes :

• impact du nombre de serveurs frontaux sur le débit pour le démarrage manuel de flux de travail déclaratifs sur plusieurs ordinateurs ;

• impact du nombre de serveurs frontaux sur le débit pour le démarrage automatique de flux de travail déclaratifs lors de la création d’éléments sur plusieurs ordinateurs ;

• impact du nombre de serveurs frontaux sur le débit pour la réalisation de tâches sur plusieurs ordinateurs.

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é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 pour déterminer si elle prendra en charge les facteurs dans votre environnement.

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 chaque section de résultats des tests plus loin dans cet article.

Configuration matérielle, paramètres et topologie

Les topologies utilisées pour ces tests utilisent un ordinateur pour la base de données de contenu et entre un et quatre ordinateurs frontaux possédant l’installation par défaut de SharePoint Server 2010. Bien que les flux de travail utilisés dans ces tests ne soient pas disponibles dans Microsoft SharePoint Foundation 2010, les résultats permettent d’évaluer des scénarios similaires sur ces déploiements. Le jeu de données utilisé pour ces tests contient une collection de sites avec un site basé sur le modèle Site d’équipe sur une base de données de contenu.

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 à quatre serveurs Web, ainsi qu’un ordinateur exécutant Microsoft SQL Server 2008. Les tests ont été réalisés avec un ordinateur client. Le serveur de bases de données et tous les serveurs Web possédaient une architecture 64 bits, tandis que l’ordinateur client possédait une architecture 32 bits.

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

Topologie de la planification de la capacité des flux de travail

Résultats des tests

Les tableaux suivants indiquent les résultats des tests pour le flux de travail dans SharePoint Server 2010. 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 indiqués dans cet article ont été menés sans temps de réflexion, délai naturel entre des opérations consécutives. Dans un environnement réel, chaque opération est suivie d’un délai lorsque l’utilisateur effectue l’étape suivante de la tâche. À l’opposé, dans le test, chaque opération était immédiatement suivie de l’opération suivante, avec pour conséquence une charge continue sur la batterie de serveurs. Cette charge peut entraîner un conflit de base de données et d’autres facteurs susceptibles d’affecter les performances.

Impact de la montée en puissance du serveur Web sur le débit

Les tests de débit suivants ont été exécutés à l’aide du flux de travail d’approbation inclus dans SharePoint Server 2010. L’association de flux de travail attribue une tâche, et toutes les instances sont exécutées sur une seule liste. Chaque instance de ce flux de travail crée les éléments suivants dans la base de données de contenu :

• une entrée dans la table Flux de travail pour le stockage de l’état du flux de travail ;

• cinq éléments de liste secondaires (une tâche et quatre éléments d’historique) ;

• quatre récepteurs d’événements pour gérer les événements sur la tâche et l’élément parents du flux de travail.

Le seuil d’ajournement des activations des flux de du travail a été défini sur une valeur très élevée afin que les opérations de flux de travail ne soient jamais mises en file d’attente. Chaque test a été exécuté cinq fois, pendant cinq minutes à chaque fois.

Débit lors du démarrage manuel

Le test décrit dans le tableau suivant indique l’impact de l’ajout de serveurs frontaux sur le débit du démarrage synchrone de flux de travail par le biais du service Web. Ce test a été exécuté avec une charge utilisateur de 25 utilisateurs simultanés appelant en continu la méthode StartWorkflow sur Workflow.asmx et sans aucune autre charge sur la batterie de serveurs. La charge utilisateur était la charge optimale jusqu’à ce que des demandes Web soient abandonnées. La liste est préremplie avec un maximum de 8000 éléments.

Le graphique suivant montre l’évolution du débit. L’ajout de serveurs frontaux n’a pas véritablement d’impact linéaire sur le débit de la batterie de serveurs, mais connaît son maximum aux alentours de trois à quatre serveurs frontaux. En résumé, le débit maximal lors du démarrage manuel des flux de travail se situe autour de 30 flux de travail par seconde et l’ajout de plus de quatre serveurs frontaux aura vraisemblablement un impact non significatif.

Débit lors du démarrage manuel

Débit lors du démarrage automatique de flux de travail avec création d’éléments

Le test décrit dans le tableau suivant indique l’impact de l’ajout de serveurs frontaux sur le débit du démarrage automatique de flux de travail lorsque des éléments sont créés. Ce test a été exécuté avec une charge utilisateur de 150 utilisateurs simultanés appelant en continu le service Web de liste pour créer des éléments de liste dans une liste et sans aucune autre opération sur le serveur. Initialement, la liste était vide.

Le graphique suivant montre l’évolution du débit. Celui-ci est très proche des opérations de démarrage manuel. Similaire au test du démarrage manuel, le débit connaît un maximum aux alentours de trois ou quatre serveurs frontaux, avec approximativement 32 flux de travail par seconde au maximum. L’ajout de plus de trois ou quatre serveurs frontaux aura un impact non significatif.

Débit lors du démarrage automatique des flux de travail

Débit lors de la réalisation des tâches

Le test décrit dans le tableau suivant indique l’impact de l’ajout de serveurs frontaux sur le débit de la réalisation des tâches de flux de travail. La liste de tâches utilisée par les flux de travail à démarrage automatique dans le test précédent a été utilisée pour la réalisation des tâches. Ce test a été exécuté avec une charge utilisateur de 25 utilisateurs simultanés appelant en continu la méthode AlterToDo sur Workflow.asmx sans aucune autre opération sur le serveur. Initialement, la liste était vide.

Le graphique suivant montre l’évolution du débit. Similaire au test du démarrage manuel, le débit connaît un maximum aux alentours de trois ou quatre serveurs frontaux, avec approximativement 32 flux de travail par seconde au maximum. L’ajout de plus de trois serveurs frontaux aura un impact non significatif.

Débit lors de la réalisation des tâches

Impact de la taille de la liste et du nombre d’instances de flux de travail sur le débit

Le test décrit dans le tableau suivant montre l’évolution du débit lorsque la taille de la liste et le nombre de flux de travail s’accroissent. Le remplissage des données a été réalisé de la façon suivante : le test des flux de travail à démarrage automatique a été exécuté en continu jusqu’à ce qu’un million d’éléments soient créés dans la liste, avec interruption à différents points de contrôle pendant le test pour que soient effectuées des mesures de débit, comme cela a été fait avec les tests de débit principaux. Les tests ont été réalisés sur une topologie 4x1.

Pour assurer la fiabilité des opérations pendant le remplissage des données, nous avons dû maintenir activée la mise en file d’attente des flux de travail afin que le nombre maximal de connexions sur le serveur de bases de données ne soit pas atteint. Si aucune connexion n’est disponible et qu’une opération de flux de travail ne peut pas se connecter à la base de données de contenu, cette opération ne peut pas s’exécuter. Pour plus d’informations sur la mise en file d’attente des flux de travail, voir Recommandations.

Débit lors du démarrage automatique lorsque le nombre d’éléments et de flux de travail s’accroît

Pour une liste, une liste de tâches et une liste d’historique uniques, le débit diminue régulièrement entre 1 000 et 100 000 éléments. Toutefois, le rythme de la dégradation diminue après ce point. Nous attribuons la dégradation du débit à plusieurs facteurs.

L’un des facteurs est le nombre de lignes ajoutées à de nombreuses tables dans la base de données de contenu par instance. Comme indiqué précédemment, les flux de travail créent plusieurs éléments de liste en plus des récepteurs d’événements enregistrés par chaque instance de flux de travail. À mesure que la table croît dans différentes étendues, l’ajout de lignes ralentit et le ralentissement global de ces ajouts prend la forme d’une dégradation plus significative que celle expérimentée avec uniquement la création d’éléments de liste.

La taille de la liste de tâches contribue à une charge supplémentaire. La comparaison du débit pour les flux de travail exécutés sur de nouvelles listes à celui pour les flux de travail exécutés sur de nouvelles listes de tâches montre que les listes de tâches ont eu un impact plus significatif sur les performances. En effet, les listes de tâches gèrent plus de récepteurs d’événements que les éléments de la liste parent. Le tableau suivant indique les différences.

Si vous comptez exécuter de nombreux flux de travail par rapport à des listes volumineuses et que vous avez besoin d’un débit supérieur au débit possible indiqué par vos tests, déterminez si vos listes de tâches peuvent être séparées entre des associations de flux de travail.

Recommandations

Cette section fournit des recommandations générales sur les performances et sur la capacité. Utilisez ces recommandations pour déterminer les caractéristiques de la topologie que vous avez créée afin de déterminer si vous devez la soumettre à une montée en puissance parallèle ou à une montée en puissance par unité.

Pour des informations spécifiques sur les configurations système minimale et recommandée requises, voir Configuration matérielle et logicielle requise (SharePoint Server 2010).

Topologies avec montée en puissance parallèle

Vous pouvez augmenter le débit des flux de travail en effectuant une montée en puissance parallèle jusqu’à quatre serveurs Web. Au-delà, une augmentation sera non significative. Le débit des flux de travail peut être restreint par les paramètres de flux de travail liés aux performances. Ces paramètres sont décrits plus précisément dans la section Paramètres liés aux performances et à la mise en file d’attente des flux de travail.

Estimation des objectifs de débit

De nombreux facteurs peuvent avoir un impact sur le débit. Ces facteurs comprennent le nombre d’utilisateurs, ainsi que le type, la complexité et la fréquence des opérations utilisateur. Les flux de travail plus complexes qui effectuent de nombreuses opérations sur la base de données de contenu ou qui gèrent davantage d’événements s’exécutent plus lentement et consomment davantage de ressources que les autres flux de travail.

Le flux de travail utilisé dans ce test crée dans la base de données de contenu plusieurs entrées qui sont intégrées aux activités des tâches. Si vous pensez que vos flux de travail auront un nombre réduit de tâches, vous pouvez espérer des caractéristiques de débit similaires. Si la plupart des flux de travail contiennent des opérations très légères, le débit peut être augmenté. Si vos flux de travail sont susceptibles de contenir de nombreuses tâches ou des opérations principales intenses, ou de faire appel à une puissance de traitement gourmande en ressources, vous pouvez vous attendre à une diminution du débit.

Outre comprendre ce que les flux de travail feront, vous devez déterminer où ils seront exécutés et si cette exécution s’effectuera par rapport à des listes volumineuses, sur lesquelles le débit diminuera avec le temps.

SharePoint Server 2010 peut être déployé et configuré de nombreuses façons. Par conséquent, il n’est pas aisé d’évaluer le nombre d’utilisateurs pouvant être pris en charge par un nombre de serveurs donné. Veillez donc à effectuer des tests dans votre propre environnement avant de déployer SharePoint Server 2010 dans un environnement de production.

Paramètres liés aux performances et à la mise en file d’attente des flux de travail

Le dispositif de flux de travail utilise un système de mise en file d’attente permettant de contrôler la pression liée au flux de travail exercée sur les ressources de la batterie de serveurs et sur la base de données de contenu. À l’aide de ce système, lorsque le nombre de flux de travail en cours d’exécution par rapport à une base de données atteint un seuil configuré par l’administrateur, les opérations de flux de travail successives sont ajoutées à la file d’attente en vue de leur exécution par le service Minuteur de flux de travail. Par défaut, ce service reçoit un lot d’éléments de travail de flux de travail par le biais de travaux du minuteur chaque minute.

Plusieurs paramètres d’administrateur de batterie liés directement ou indirectement au mécanisme de mise en file d’attente ont un impact sur les performances et sur la montée en puissance relatives au flux de travail. Les sections suivantes décrivent ce que font ces paramètres et la façon dont vous pouvez les ajuster pour satisfaire aux contraintes de performance.

Présentation des paramètres de file d’attente de base

Les administrateurs de batterie peuvent ajuster les paramètres suivants pour configurer les caractéristiques de base du système de mise en file d’attente :

• Seuil d’ajournement des activations des flux de du travail (Set-SPFarmConfig –WorkflowPostponeThreshold <entier>)

  Nombre maximal de flux de travail pouvant s’exécuter par rapport à une base de données de contenu avant que des demandes et des opérations supplémentaires ne soient mises en file d’attente. Les flux de travail mis en file d’attente affichent l’état Démarrage en cours. Il s’agit d’un paramètre à l’échelle de la batterie de serveurs dont la valeur par défaut est 15. Ce paramètre représente le nombre d’opérations de flux de travail en cours de traitement à la fois, pas le nombre maximal de flux de travail pouvant être en cours. À mesure que les opérations de flux de travail sont achevées, des opérations successives peuvent s’exécuter.

• Taille du lot de remise des événements de flux de travail (Set-SPWorkflow –BatchSize <entier>)

  Le service Minuteur de flux de travail est une exception au seuil d’ajournement ; il récupère les lots d’éléments de la file d’attente et les exécute un par un. Le nombre de ces lots peut être supérieur au seuil d’ajournement. Le nombre d’éléments de travail que le service reçoit par exécution est défini à l’aide de la propriété BatchSize. La propriété BatchSize peut être définie une fois par instance de service. La valeur par défaut est 100. Lorsque le service Minuteur de flux de travail s’exécute sur des serveurs d’applications qui ne sont pas configurés en tant que serveurs frontaux, il est nécessaire que les paramètres de configuration des flux de travail dans Web.config soient définis dans la base de données de configuration. Cette opération doit être réalisée par le biais d’un script qui appelle UpdateWorkflowConfigurationSettings() sur l’objet SPWebApplication, ce qui permettra de copier les paramètres Web.config à partir d’un serveur frontal.

• Fréquence du travail du minuteur de flux de travail (Set-SPTimerJob job-workflow –schedule <chaîne>)

  La fréquence à laquelle le service Minuteur de flux de travail s’exécute peut être ajustée par le biais de paramètres de travail du minuteur. Par défaut, le service est défini pour s’exécuter toutes les cinq minutes. Cela signifie qu’un délai de cinq minutes peut s’écouler avant que ne soient traités les éléments de travail se trouvant en haut de la file d’attente.

  Notes

  Les éléments de travail planifiés, tels que les expirations d’échéance de tâche, sont sélectionnés par le même mécanisme de minuteur. Par conséquent, ils subiront le même délai.

Le service Minuteur de flux de travail peut être désactivé sur chaque serveur à l’aide de la fonctionnalité Administration de services partagés de l’Administration centrale. Par défaut, il s’exécute sur chaque serveur frontal de la batterie de serveurs. Chaque travail passe en revue toutes les applications Web et toutes les bases de données de contenu de la batterie de serveurs.

La combinaison du seuil d’ajournement, de la taille de lot et de la fréquence du minuteur permet de limiter les opérations de flux de travail par rapport à la base de données. Le débit maximal dépend de la rapidité avec laquelle les opérations sont mises en file d’attente et traitées à partir de celle-ci.

Par exemple, avec les paramètres par défaut, un service du minuteur unique et une base de données de contenu unique, si la file d’attente comprend 1 000 éléments, l’exécution de tous ces éléments nécessite dix exécutions du travail du minuteur, soit une période de 50 minutes. Toutefois, si vous définissez la taille du lot sur 1 000 et que vous configurez le travail du minuteur de manière à ce qu’il s’exécute chaque minute, toutes les opérations commencent à être exécutées après une minute. Si vous définissez le seuil d’ajournement sur un niveau plus élevé, davantage d’opérations sont exécutées de façon synchrone, ce qui réduit le nombre de demandes mises en file d’attente et le temps total nécessaire au traitement de ces flux de travail.

Si vous ne souhaitez pas que les flux de travail s’exécutent sur les serveurs frontaux et qu’il n’est pas nécessaire que les opérations se produisent immédiatement, vous pouvez isoler le service Minuteur de flux de travail de manière à ce qu’il s’exécute sur des serveurs d’applications spécifiques, définir le seuil d’ajournement sur un nombre très réduit afin que les flux de travail s’exécutent généralement dans le service du minuteur et définir une taille de lot élevée afin que celui-ci reçoive les éléments plus rapidement et plus fréquemment. Si vous souhaitez que les flux de travail s’exécutent de façon plus synchrone dans le système, définissez le seuil d’ajournement sur une valeur plus élevée afin que les flux de travail ne soient pas ajournés souvent et que leur effet soit plus immédiat.

Modifiez ces paramètres de manière à optimiser le fonctionnement des flux de travail. Il est recommandé d’expérimenter différents paramètres et de les tester afin de les optimiser en fonction de vos environnements et de vos contraintes.

Ajustement des paramètres pour la mise en file d’attente

Si la batterie de serveurs est susceptible de subir une lourde charge de flux de travail pendant de longues périodes ou que de nombreux événements de délai doivent être mis en attente à partir des flux de travail dans le système, le nombre d’opérations de flux de travail mises en file d’attente est appelé à augmenter. Outre les paramètres de file d’attente de base, vous pouvez être amené à ajuster les paramètres suivants afin de garantir l’intégrité de la file d’attente :

• Taille du lot de remise des événements de l’élément de travail

  La table que le flux de travail utilise pour les événements mis en file d’attente est une table d’éléments de travail générale qui est partagée avec d’autres fonctionnalités non liées au flux de travail dans SharePoint Server 2010. Par conséquent, il existe un autre travail du minuteur qui enlève de la file d’attente les éléments de travail non liés au flux de travail. Similaire à la taille du lot de remise des événements de flux de travail, la taille du lot de remise des événements de l’élément de travail spécifie le nombre d’éléments de travail non liés au flux de travail enlevés simultanément de la file d’attente.

• Fréquence du travail du minuteur de basculement de flux de travail

  Dans de rares circonstances, si les événements de flux de travail ne peuvent pas être remis à une instance de flux de travail, la remise des événements est planifiée sur la file d’attente en tant qu’élément de travail de basculement à réessayer ultérieurement (tout d’abord 5 minutes plus tard, puis 10 minutes en cas de nouvel échec, puis 20 minutes et ainsi de suite). Un travail du minuteur de basculement de flux de travail enlève de la file d’attente les éléments de travail de basculement, et ce paramètre ajuste la fréquence à laquelle s’exécute le minuteur de basculement. Par défaut, celui-ci s’exécute toutes les 15 minutes.

• Taille du lot du basculement de flux de travail

  Similaire aux paramètres de taille de lot des éléments de flux de travail et de travail, ce paramètre contrôle le nombre d’événements de basculement que chaque travail du minuteur de basculement enlèvera de la file d’attente.

  Étant donné que de nombreux travaux du minuteur fonctionnent sur la même table, une quantité élevée d’éléments mis en file d’attente risque de provoquer un conflit de base de données, de diminuer le débit et de porter atteinte à la fiabilité. Pour réduire le risque de conflit, il est recommandé d’effectuer les opérations suivantes :

  • Équilibrez le seuil d’ajournement et la taille de lot des flux de travail afin que celle-ci soit suffisamment petite ou que la fréquence des travaux du minuteur soit suffisamment élevée pour qu’un travail du minuteur soit achevé avant le démarrage du travail du minuteur suivant, afin d’éviter l’exécution en parallèle d’un nombre trop élevé de travaux du minuteur voués à l’échec.

  • Pour éviter les verrous de table, ne définissez aucun des deux paramètres de taille de lot sur une valeur supérieure à 5 000.

Amélioration de la montée en puissance pour les listes de tâches et d’historique

Les flux de travail génèrent une quantité élevée de tâches et d’éléments d’historique par instance. Par défaut, ces listes sont indexées afin de faciliter la montée en puissance, mais à mesure qu’elles s’accroissent, les performances diminuent. Pour réduire le rythme de cette diminution, conservez des listes d’historique et de tâches distinctes pour les différentes associations de flux de travail et modifiez régulièrement ces listes dans les paramètres des associations de flux de travail lorsqu’elles deviennent volumineuses.

Le flux de travail possède également un travail du minuteur quotidien (job-workflow-autoclean) qui supprime automatiquement les instances de flux de travail et les tâches pour les instances achevées depuis plus de 60 jours. Laissez ce travail du minuteur activé afin que les listes de tâches et les événements sur ces listes demeurent aussi nets que possible. Si des données doivent être conservées, écrivez-les dans d’autres listes ou à d’autres emplacements d’archivage. Les éléments d’historique de flux de travail ne sont pas supprimés par ce travail du minuteur. Si vous devez les effacer, vous devez recourir à un script ou procéder manuellement par le biais de l’interface utilisateur de la liste.

Autres considérations

La suppression de colonnes d’une liste entraîne une opération de base de données proportionnelle au nombre d’éléments contenus dans la liste. La suppression d’associations de flux de travail entraîne la suppression de la colonne d’état de flux de travail de la liste. Cela engendre une opération importante sur les listes volumineuses. S’il s’avère qu’une liste possède des millions d’éléments, définissez le flux de travail sur Aucune nouvelle instance au lieu de supprimer des flux de travail.

Résolution des problèmes

Serveurs Web

Le tableau suivant indique les compteurs de performance et les processus à surveiller pour les serveurs Web d’une batterie de serveurs.

Serveurs de bases de données

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

See Also

Other Resources

Évolutivité et performances des flux de travail dans Windows SharePoint Services 3.0 (https://go.microsoft.com/fwlink/?linkid=207353&clcid=0x40C) (éventuellement en anglais)