Conception de personnalisation évolutive : Problèmes de concurrence

Notes

Il s′agit de la troisième d′une série de rubriques concernant la conception de personnalisation évolutive. Pour commencer dès le début, voir Conception de personnalisation évolutive dans Microsoft Dataverse. La rubrique précédente Conception de personnalisation évolutive : transactions de base de données décrivait comment les transactions de base de données sont appliquées et l′effet qu′elles ont sur différents types de personnalisations.

Lorsque vous avez des demandes concurrentes, les risques de collisions sur les verrous devient plus grandes. Plus les transactions sont longues, plus les verrous sont conservés longtemps. Les chances de collision sont toujours supérieures et l′impact général serait plus grand sur les utilisateurs finaux.

Vous devez également être au courant des diverses manières que l′activité peut être basée sur l′application, chacune desquelles instaure des verrous qui peuvent entraîner un conflit avec d′autres actions dans le système. Dans ces cas, un verrouillage empêche les incohérences des données se produisent lors du chevauchement d′actions sur les mêmes données.

Des zones clés sont à prendre en compte dans la conception, et que vous devez vérifier si vous voyez les problèmes, sont les suivantes :

• Activité orientée utilisateur : Directement via l′interface utilisateur.
• Actions asynchrones : Activité qui se passe ultérieurement à la suite d′autres actions. Lorsque cette activité sera traitée n′est pas connu au moment où est déclenchée cette action.
• Activités par lots : Soit déclenchées depuis Dataverse (telles que le traitement de tâches de suppression en bloc ou la synchronisation côté serveur), ou depuis des sources externes comme l′intégration à partir d′un autre système.

Opérations asynchrone en parallèle

On croît souvent à tort que les workflows asynchrones ou les plug-ins sont traités en séquence depuis une file d′attente et qu′il n′y aurait pas de conflit entre eux. Ce n′est pas exact, car Dataverse pour les applications traite plusieurs activités asynchrones en parallèle dans chaque instance de service asynchrone et entre plusieurs instances du service asynchrones réparties sur différents serveurs pour augmenter le débit. Chaque service asynchrone récupère en fait des tâches à effectuer par lots d′environ 20 par configuration et chargement basés sur le service.

Si vous initiez plusieurs activités asynchrones du même événement sur le même enregistrement, elles sont susceptibles de continuer 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 de déclenchement se produit, par exemple la création d′un compte, une logique asynchrone dans Dataverse pour les applications peut créer des entrées dans l′Entité AsyncOperation (tâche système) de chaque processus ou une action à exécuter. Le service asynchrone surveille ce tableau, prélève les demandes en attente par lots, puis les traite. Étant donné que les workflows sont déclenchés en même temps, il est très probable qu′ils soient prélevé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 montre comment les transactions de base de données et les problèmes de concurrence doivent être pris en compte lorsque vous concevez des personnalisations évolutives.

Sérialisation et délais d′expiration

Un niveau élevé de sérialisation est généralement ce qui transforme les blocages en délais d′expiration et en un débit médiocre. Lorsque vous avez de nombreuses demandes simultanées, une fois qu′elles sont sérialisées et que leur traitement prend du temps, chaque demande prend à son tour plus de temps jusqu′à ce que vous ayez commencé à atteindre les délais d′interruption et par conséquent reçu des messages d′erreur.

Le délai d′interruption des plug-ins commence à partir du moment où il est déclenché. Une délai d′expiration SQL est calculée sur la demande de base de données, donc si une requête se bloque en attendant longtemps, elle peut arriver à expiration.

Chaîne d′actions

Non seulement il est important de comprendre les demandes spécifiques dans les activités déclenchées directement, il est également nécessaire de prendre en compte où une chaîne d′événements connexes peut se produire.

Chaque demande de message effectuée dans un plug-in ou comme étape dans un workflow 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 déroulera dans la même transaction, étendant la durée de vie de cette transaction et des verrous placés probablement beaucoup plus longtemps qu′il ne peut être réalisé.

L′impact général peut être beaucoup plus élevé qu′initialement réalisé. Cela peut se produire souvent accidentellement lorsque plusieurs personnes accumulent l′implémentation, ou qu′elle évolue avec le temps.

Exécution dans des contraintes de plateforme

C′est ici que les contraintes de plateforme peuvent survenir. 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, des conséquences involontaires surviendront dans d′autres zones du système et sur d′autres utilisateurs. Il est donc important d′éviter ce type d′activité de gêner les performances système.

Bien que pour éviter les erreurs il peut être simple d′alléger les contraintes de la plateforme, cela ne permet pas de traiter l′impact le plus fondamental sur l′évolutivité et les performances globales du système. Cela doit être traité en corrigeant et en empêchant le comportement de déclencher les contraintes en premier lieu.

Impact sur l′utilisation

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

Le problème initial est les verrous et par conséquent le blocage du système. Ce entraîne un ralentissement des délais de réponse utilisateur, qui est alors amplifié par des délais de réponse utilisateur imprévisibles et non fiables, souvent dans un domaine particulier du système.

Dans un cas extrême ou en cas de chargement plus lourd que la normale, cela peut ensuite se produire dans tout processus par lots en arrière-plan avec un débit médiocre. Par la suite cela peut se répercuter sous forme d′erreurs se produisant dans le système.

Il est courant qu′en enquêtant sur les erreurs d′expiration SQL, les utilisateurs rapportent également des délais de réponse médiocres et imprévisibles, et que la connexion n′a pas été établie entre eux comme problèmes connexes.

Étapes suivantes

Comprenez 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 conceptions de transaction

Notes

Pouvez-vous nous indiquer vos préférences de langue pour la documentation ? Répondez à un court questionnaire. (veuillez noter que ce questionnaire est en anglais)

Le questionnaire vous prendra environ sept minutes. Aucune donnée personnelle n’est collectée (déclaration de confidentialité).