Partager via

Meilleures pratiques de persistance

  • Article

Ce document traite des meilleures pratiques de conception et configuration de workflow associées à la persistance de workflow.

Conception et implémentation de workflow durables

En règle générale, les workflows fonctionnent pendant de courtes périodes entrelacées avec des périodes d'inactivité au cours desquelles ils sont attente d'un événement. Cet événement peut être un message ou un minuteur d'expiration. Pour pouvoir décharger l'instance de workflow lorsqu'elle devient inactive, l'hôte de service doit rendre cette instance persistante. Cela s’avère possible uniquement si l’instance de workflow n’est pas dans une zone de non-persistance (par exemple, en attente d’une transaction ou d’un rappel asynchrone). Pour permettre le déchargement d’une instance de workflow inactive, l’auteur du workflow doit utiliser les portées de transaction et les activités asynchrones uniquement pour des actions de courte durée. Plus particulièrement, il doit conserver les activités de délai dans ces zones de non-persistance aussi brèves que possible.

Un workflow peut uniquement être rendu persistant si tous les types de données qu'il utilise sont sérialisables. En outre, les types personnalisés utilisés dans les workflows persistants doivent être sérialisables avec NetDataContractSerializer pour pouvoir être rendus persistants par SqlWorkflowInstanceStore.

Une instance de workflow ne peut pas être récupérée en cas d'échec de l'hôte ou de l'ordinateur, si elle n'est pas persistante. En règle générale, il est recommandé de rendre persistante une instance de workflow tôt dans son cycle de vie.

Si le workflow est occupé pendant longtemps, il est recommandé de rendre persistante l'instance de workflow régulièrement pendant toute cette période. Pour ce faire, vous pouvez ajouter des activités Persist dans l'ensemble de la séquence des activités qui maintiennent l'instance de workflow occupée. De cette façon, un recyclage de domaine d'application, un échec de l'hôte ou de l'ordinateur n'entraîne pas la restauration au début de la période d'occupation. Soyez conscient que l'ajout d'activités Persist à votre workflow peut provoquer une diminution des performances.

Windows Server AppFabric simplifie grandement la configuration et l'utilisation de la persistance. Pour plus d’informations, consultez Persistance Windows Server AppFabric.

Configuration des paramètres d'évolutivité

Les conditions requises en termes d'évolutivité et de performance déterminent la configuration des paramètres suivants :

Ces paramètres doivent être définis comme suit, en fonction du scénario actuel.

Scénario : petit nombre d'instances de workflow qui nécessitent un temps de réponse optimal

Dans ce scénario, toutes les instances de workflow doivent rester chargées lorsqu'elles deviennent inactives. Affectez une valeur élevée à TimeToUnload. L'utilisation de ce paramètre empêche une instance de workflow de se déplacer entre les ordinateurs. Utilisez ce paramètre uniquement si une ou plusieurs des conditions suivantes sont remplies :

  • Une instance de workflow reçoit un seul message durant toute sa durée de vie.

  • Toutes les instances de workflow s'exécutent sur un seul ordinateur.

  • Tous les messages reçus par une instance de workflow sont reçus par le même ordinateur.

Utilisez des activités Persist ou affectez la valeur 0 à TimeToPersist pour permettre la récupération de votre instance de workflow après un échec de l'ordinateur ou de l'hôte de service.

Scénario : les instances de workflow sont inactives pendant de longues périodes

Dans ce scénario, affectez la valeur 0 à la propriété TimeToUnload pour libérer les ressources dès que possible.

Scénario : les instances de workflow reçoivent plusieurs messages dans une courte période

Dans ce scénario, affectez la valeur 60 à la propriété TimeToUnload si ces messages sont reçus par le même ordinateur. Cela empêche une séquence rapide de déchargement et chargement d'une instance de workflow. Par ailleurs, l'instance n'est pas conservée trop longtemps en mémoire.

Affectez la valeur 0 à la propriété TimeToUnload, et BasicRetry ou AggressiveRetry à la propriété InstanceLockedExceptionAction si ces messages peuvent être reçus par des ordinateurs distincts. Cela permet à l'instance de workflow d'être chargée par un autre ordinateur.

Scénario : le workflow utilise des activités de délai avec des durées courtes

Dans ce scénario, SqlWorkflowInstanceStore vérifie régulièrement dans la base de données de persistance la présence d'instances qui doivent être chargées en raison d'une activité Delay arrivée à expiration. Si SqlWorkflowInstanceStore trouve un minuteur qui va expirer au cours de la fréquence d'interrogation suivante, le magasin d'instances de workflow SQL réduit la fréquence. L'interrogation suivante aura lieu dès que le minuteur aura expiré. De cette façon, le magasin d'instances de workflow SQL obtient une haute précision des minuteurs qui s'exécutent plus longtemps que la fréquence définie par la propriété RunnableInstancesDetectionPeriod. Pour permettre le traitement en temps voulu de délais plus courts, l'instance de workflow doit rester en mémoire pendant au moins une fréquence d'interrogation.

Affectez la valeur 0 à la propriété TimeToPersist pour écrire le délai d'expiration dans la base de données de persistance.

Affectez une valeur supérieure ou égale à TimeToUnload à RunnableInstancesDetectionPeriod pour conserver l'instance en mémoire pendant au moins une fréquence d'interrogation.

Il est déconseillé de réduire RunnableInstancesDetectionPeriod car cela provoque une charge accrue sur la base de données de persistance. Chaque hôte de service qui utilise SqlWorkflowInstanceStore interroge la base de données une seule fois par période de détection. Affecter un intervalle de temps trop court à RunnableInstancesDetectionPeriod peut provoquer une diminution des performances du système si le nombre d'hôtes de service est trop élevé.

Configuration du magasin d'instances de workflow SQL

Les paramètres de configuration du magasin d'instances de workflow SQL sont les suivants :

InstanceEncodingOption
Ce paramètre fait en sorte que SqlWorkflowInstanceStore compresse l'état de l'instance de workflow. La compression réduit la quantité de données stockées dans la base de données de persistance et le trafic réseau si la base de données de persistance réside sur un serveur de base de données dédié. Si la compression est utilisée, des ressources de calcul sont nécessaires pour compresser et extraire l'état de l'instance. Dans la plupart des cas, la compression améliore les performances.

InstanceCompletionAction
Ce paramètre fait en sorte que SqlWorkflowInstanceStore conserve ou supprime les instances terminées. La conservation des instances terminées augmente la capacité de stockage requise de la base de données de persistance et la taille des tables, ce qui allonge les temps de recherche dans les tables. Sauf si les instances terminées sont nécessaires pour le débogage ou l'audit, il est préférable de faire en sorte que SqlWorkflowInstanceStore supprime ces instances. Les instances supprimées ne doivent être conservées que si l'utilisateur établit un processus permettant éventuellement de les supprimer. Notez que les clés de corrélation ne peuvent pas être réutilisées tant que l'instance de workflow terminée réside dans le magasin d'instances.

RunnableInstancesDetectionPeriod
Ce paramètre définit l'intervalle maximal dans lequel SqlWorkflowInstanceStore vérifie dans la base de données de persistance la présence d'instances qui doivent être chargées si une activité Delay arrive à expiration. Si SqlWorkflowInstanceStore trouve un minuteur qui va expirer au cours de la fréquence d'interrogation suivante, il réduit l'intervalle d'interrogation de façon à ce que l'interrogation suivante se produise après l'expiration du minuteur. De cette façon, le magasin d'instances de workflow SQL obtient une haute précision des minuteurs qui s'exécutent plus longtemps que la fréquence définie par la propriété RunnableInstancesDetectionPeriod.

Il est déconseillé de réduire RunnableInstancesDetectionPeriod, car cela provoque une charge accrue sur la base de données de persistance. Chaque hôte de service qui utilise SqlWorkflowInstanceStore interroge la base de données une seule fois par période de détection. Affecter un intervalle trop court à RunnableInstancesDetectionPeriod peut provoquer une diminution des performances du système si le nombre d'hôtes de service est trop élevé.

HostLockRenewalPeriod
Ce paramètre définit l'intervalle dans lequel l'hôte renouvelle son verrou dans la base de données de persistance. Réduire cet intervalle permettra la récupération plus rapide de l'instance de workflow après un échec de l'ordinateur ou de l'hôte. Par contre, une période de renouvellement de verrou courte augmente la charge sur la base de données de persistance. Chaque hôte de service qui utilise SqlWorkflowInstanceStore mettra à jour ses verrous dans la base de données une seule fois par période de renouvellement. Si un ordinateur exécute plusieurs hôtes de service, assurez-vous que la charge provoquée par le renouvellement de verrou n'altère pas les performances du système. Le cas échéant, envisagez d'augmenter le HostLockRenewalPeriod.

InstanceLockedExceptionAction
S'il est activé, SqlWorkflowInstanceStore effectue une nouvelle tentative de chargement d'une instance verrouillée au cours des trente secondes suivantes. Affectez BasicRetry ou AggressiveRetry à la propriété InstanceLockedExceptionAction si le workflow reçoit plusieurs messages dans une courte période et ces messages sont reçus par des ordinateurs distincts.

Étant donné que le mécanisme de tentative de chargement n'entraîne pas une surcharge de performance tant que les tentatives de chargement ne sont pas exécutées, la propriété InstanceLockedExceptionAction doit toujours être activée.