Conception de personnalisation évolutive : problèmes de concurrence

Lorsque vous avez des demandes simultanées, le risque de collisions sur les verrous devient plus élevé. Plus les transactions durent longtemps, plus longtemps les verrous sont retenus. Les chances sont encore plus élevées de collision et l’impact global serait plus important sur les utilisateurs finaux.

Vous devez également connaître les différentes façons dont l’activité peut être pilotée sur l’application, chacune prenant des verrous susceptibles d’entraîner un conflit avec d’autres actions au sein du système. Dans ces cas, le verrouillage empêche les incohérences de données qui se produisent lorsque des actions se chevauchent sur les mêmes données.

Voici quelques domaines clés pour lesquels prendre en compte la conception et vérifier si vous rencontrez des problèmes :

• Activité pilotée par l’utilisateur : directement via l’interface utilisateur.
• Actions asynchrones : activité qui se produit ultérieurement suite à d’autres actions. Lorsque cette activité sera traitée, elle n’est pas connue au moment où l’action de lancement est déclenchée.
• Activités batch : pilotées à partir de Dataverse, telles que les travaux de suppression en bloc ou le traitement de synchronisation côté serveur), ou pilotées par des sources externes telles que l’intégration à partir d’un autre système.

Opérations asynchrones en parallèle

Une idée fausse courante est que les flux de travail asynchrones ou les plug-ins sont traités en série à partir d’une file d’attente et qu’il n’y aurait pas de conflit entre eux. Cela n’est pas exact, car Dataverse traite plusieurs activités asynchrones en parallèle dans chaque instance de service asynchrone et entre les instances de service asynchrone réparties sur différents serveurs pour augmenter le débit. Chaque service asynchrone récupère en fait les travaux à effectuer par lots d’environ 20 par service en fonction de la configuration et de la charge.

Si vous lancez plusieurs activités asynchrones à partir du même événement sur le même enregistrement, elles sont susceptibles de traiter en parallèle. Lorsqu′elles sont déclenchées sur le même enregistrement, un schéma commun consiste en mises à jour effectues à nouveau sur le même enregistrement parent ; par conséquent, l′opportunité de conflit est élevée.

Lorsqu’un événement déclencheur se produit, tel que la création d’un compte, la logique asynchrone dans Dataverse peut créer des entrées dans l’entité AsyncOperation (travail système) pour chaque processus ou action à entreprendre. Le service asynchrone surveille cette table, récupère les demandes en attente par lots, puis les traite. Étant donné que les flux de travail sont déclenchés en même temps, ils sont très susceptibles d’être récupérés dans le même lot et traités en même temps.

Pourquoi il est important de comprendre les transactions

L’exemple de numérotation automatique fournit un scénario qui illustre la façon dont les transactions de base de données et les problèmes d’accès concurrentiel doivent être pris en compte lors de la conception de personnalisations évolutives.

Sérialisation et délais d’expiration

Un degré élevé de sérialisation est généralement ce qui transforme le blocage en délais d’attente et un débit médiocre. Lorsque vous avez de nombreuses requêtes simultanées, une fois qu'elles s'enchaînent et prennent beaucoup de temps à traiter, chaque requête prend de plus en plus de temps à son tour, jusqu'à ce que vous commenciez à rencontrer des délais d'attente et donc des erreurs.

Le délai d’expiration du plug-in commence à partir du moment où il est lancé. Un délai d’expiration SQL est calculé sur la requête de base de données. Par conséquent, si une requête bloque l’attente pendant longtemps, elle peut expirer.

Chaîne d’actions

En plus de comprendre les requêtes spécifiques dans les activités déclenchées directement, il est également nécessaire de prendre en compte l’endroit où une chaîne d’événements connexes peut se produire.

Chaque demande de message effectuée dans un plug-in ou en tant qu’étape d’un flux de travail synchrone déclenche non seulement l’action directe, mais peut également entraîner le déclenchement d’autres plug-ins et workflows synchrones. Chacune de ces activités synchrones se produira dans la même transaction, prolongeant ainsi la durée de vie de cette transaction et des éventuels verrous détenus, probablement bien plus longtemps que prévu.

L’effet global peut être beaucoup plus grand que celui initialement réalisé. Cela peut souvent se produire involontairement lorsque plusieurs personnes créent l’implémentation ou évoluent au fil du temps.

Faire face aux contraintes de la plateforme

C’est là que les contraintes de plateforme peuvent entrer. Et en réalité ce type de comportement est exactement ce contre quoi les contraintes protègent le système dans son ensemble.

Chaque fois que ce niveau de retard de traitement se produit, il aura des conséquences inattendues dans d’autres domaines du système et sur d’autres utilisateurs. Il est donc important d’empêcher ce type d’activité d’interférer avec les performances du système.

Bien que le moyen facile d’éviter les erreurs peut être de détendre les contraintes de plateforme, cela ne traite pas de l’impact plus fondamental sur l’évolutivité globale et les performances du système. Cela doit être résolu en corrigeant et en empêchant le comportement déclenchant les contraintes en premier lieu.

Impact sur l’utilisation

Ce qui a souvent un impact sur l’utilisation est une série en cascade d’implications de ce comportement.

Le problème initial est des verrous et, par conséquent, le blocage dans le système. Cela conduit à ralentir les temps de réponse des utilisateurs, qui sont ensuite amplifiés comme des temps de réponse utilisateur imprévisibles et peu fiables, souvent dans une zone particulière du système.

Dans le cas extrême ou avec une charge plus lourde que la normale, cela peut alors se manifester dans n'importe quel traitement par lots en arrière-plan avec une mauvaise performance. Finalement, cela peut mener à des erreurs qui se produisent dans le système.

Il est courant que lors de l’examen des erreurs de délai d’expiration SQL, les utilisateurs signalent également des temps de réponse médiocres et imprévisibles, et la connexion n’a pas été établie entre ces erreurs en tant que problèmes connexes.

Étapes suivantes

Comprendre les modèles de conception que vous pouvez appliquer (ou éviter) pour réduire les problèmes de performances. Plus d’informations : Conception de personnalisation évolutive : modèles de conception de transaction