Conception de personnalisation évolutive dans Microsoft Dataverse

Notes

Il s′agit de la première d′une série d’articles concernant la conception de personnalisation évolutive. Même si ce contenu a été divisé en articles distincts, il présente une vue complète des concepts, des problèmes, et des stratégies entourant la conception de personnalisations évolutives. Chaque article est basé sur des concepts établis dans les articles précédents. Vous pouvez télécharger ces articles comme document PDF simple si vous voulez les lire en mode hors connexion. Sélectionnez le lien Télécharger le PDF dans la table des matières.

Ce contenu fait uniquement référence aux tables standard Dataverse qui utilisent Azure SQL. Les tables élastiques Dataverse utilisent Azure Cosmos DB et ne prennent pas en charge les transactions. Les tables élastiques ont des caractéristiques différentes. En savoir plus sur les tables élastiques

Dataverse se protège, ainsi que ses utilisateurs pour de longues activités qui peuvent affecter les délais de réponse de l′utilisateur effectuant une demande et la stabilité et la réactivité du système pour les autres utilisateurs.

Certaines personnes mettant en œuvre des solutions Dataverse font face à des erreurs envoyées par la plateforme ou la base de données Microsoft SQL Server sous-jacente lorsque ces mesures de protection prennent effet. Ces erreurs sont souvent interprétés comme si la plateforme ne pouvait pas se mettre à l′échelle ou mettait fin ou limitait les demandes de manière incorrecte dans le système.

Ce contenu est basé des expériences d′investigation et de traitement des causes sous-jacentes réelles de la majorité de ces types de défis. Ces articles décrivent comment la plateforme se protège de l′impact de ces demandes imposées au système et expliquent pourquoi ce comportement est le plus souvent le résultat de mises en œuvre personnalisées ne comprenant pas l′impact sur le blocage et l′utilisation des transactions au sein de la plateforme.

Ce contenu explique également comment l′optimisation d′une mise en œuvre personnalisée pour éviter ces types de comportements permet d′éviter non seulement des erreurs de plateforme, mais d′obtenir également de meilleures performances et expériences utilisateur. Il fournit de bonnes pratiques de conception et identifie les erreurs fréquentes à éviter.

Le défi

L′investigation et le traitement des défis dans ce domaine démarrent généralement lorsque certains types d′erreurs et de symptômes apparaissent dans le système. Ces erreurs et symptômes sont souvent perçus comme des problème de la plateforme et l′étape corrective nécessaire consiste à relâcher les contraintes de la plateforme qui déclenchent généralement une demande d′exécution lente pour devenir une erreur signalée.

En réalité, bien que les erreurs puissent être évitées à court terme en détendant certaines des contraintes de la plateforme, ces contraintes sont là pour de bonnes raisons et sont conçues pour empêcher une action excessivement longue d′affecter d′autres utilisateurs ou les performances système. Bien que les contraintes puissent être détendues pour éviter les erreurs, les utilisateurs rencontrent toujours des délais de réponse lents et ces problèmes de performance affectent l′expérience d′autres utilisateurs du système également.

Dès lors, il est préférable d′étudier les principales raisons pour lesquelles ces contraintes sont déclenchées et entraînent des erreurs, puis d′optimiser les personnalisations de code pour les éviter. Cette approche fournit un système plus cohérent et plus réactif aux utilisateurs.

Symptômes courants

Ces types de problèmes présentent généralement une combinaison de symptômes courants comme indiqué dans le tableau suivant.

Symptôme	Description
Demandes lentes	Les utilisateurs voient des délais de réponse lents du système dans des zones spécifiques, par exemple, dans certains formulaires et requêtes
Erreurs SQL génériques	Certaines actions répondent à une erreur de plateforme signalant une erreur SQL générique. Cette erreur se traduit souvent sur une couche de plateforme en un délai d′expiration SQL.
Interblocages	Erreurs de plateforme indiquant qu′un interblocage s′est produit, ce qui a forcé l′action à pendre fin et entrainé une restauration.
Débit limité	En particulier dans les scénarios de chargement par lots, cela indique souvent un débit réellement lent, beaucoup plus lent que la normale.
Erreurs intermittentes/performances lentes	Un indicateur important de ces comportements est celui où la même action peut être très rapide ou incroyablement lente, et la réessayer permet de fonctionner bien plus rapidement ou d′éviter une erreur

En réalité une combinaison de ces symptômes peut et est souvent signalée ensemble lorsque ces défis se présentent. Ce n′est pas toujours le cas que ces symptômes sont un indicateur de problèmes avec la conception. D′autres problèmes, tels que les limitations d′E/S du disque dans la base de données ou d′un bogue de produit, peuvent entraîner des symptômes similaires. Mais la cause la plus courante de ces types de symptômes, et par conséquent qu′il est intéressant de vérifier, est liée directement à la conception de la mise en œuvre personnalisée et de ses répercutions sur le système.

Pourquoi s′inquiéter ? Dataverse ne gère-t-il pas cela... ?

C′est le cas dans une certaine mesure... Mais il utilise des verrouillages et des transactions pour protéger le système des conflits lorsque cela est nécessaire.

Nous fournissons également des options vous permettant de faire des choix concernant votre scénario spécifique et de décider où il est important de contrôler l′accès aux données. Mais ces choix peuvent être faits de manière incorrecte, et il est possible d′introduire des conséquences involontaires dans le code personnalisé. Ces problèmes ont généralement un impact sur l′expérience utilisateur via des délais de réponse plus lents, il est donc important de comprendre que les implications de certaines actions peuvent aboutir à des résultats plus cohérents et meilleurs pour les utilisateurs.

Comprendre les causes

Les symptômes courants ont des causes qui forcent des demandes spécifiques à s′exécuter lentement et à déclencher ensuite des contraintes de plateforme. Le diagramme suivant illustre des symptômes courants avec certaines des causes principales courantes de ces symptômes.

L′impact sous-jacent des transactions longues, du blocage de la base de données et des requêtes complexes peuvent se chevaucher l′un l′autre et amplifier leurs effets pour entraîner ces symptômes. Par exemple, une série de demandes longues qui sont indépendantes les unes des autres peut entraîner des délais de réponse utilisateur lents, mais uniquement une fois qu′ils ont besoin d′accéder aux mêmes ressources les délais de réponse deviennent si lents qu′ils déclenchent des erreurs.

Conception de contraintes de plateforme

La plateforme Dataverse comporte un certain nombre de contraintes délibérées qu′elle impose pour empêcher une action d′avoir un impact trop préjudiciable sur le reste du système et, par conséquent, sur les utilisateurs. Même si ce comportement peut être frustrant, car il empêche des demandes spécifiques de s′exécuter et entraîne souvent des questions sur la suppression des contraintes, il s′agit rarement d′une bonne approche lorsque vous considérez plus largement les implications.

Lorsque la plateforme est utilisée comme prévu et qu′une mise en œuvre est optimisée, il est très rare qu′il existe un scénario dans lequel ces contraintes se produisent. L′exécution dans la contrainte est presque toujours une indication de comportements qui relieront ressources excessivement dans le système. Cela signifie que d′autres demandes du même utilisateur ou d′autres utilisateurs ne peuvent pas être traitées. Bien qu′il puisse être possible de relâcher la contrainte sur la demande étant bloquée, cela signifie en fait que les ressources qu′elle consomme sont reliées pendant bien plus longtemps ce qui entraîne des répercussions plus grandes sur les autres utilisateurs.

Au cœur de ces contraintes on retrouve l′idée que la plateforme Dataverse est conçue pour prendre en charge une application transactionnelle et multi-utilisateurs où une réponse rapide à la demande de l′utilisateur est prioritaire. Elle n′est pas conçue pour être une plateforme pour des traitements longs ou par lots. Il est possible de diriger une série de demandes courtes vers Dataverse mais Dataverse n′est pas conçu pour gérer le traitement par lots. Également, là où des activités exécutent un traitement itératif volumineux, Dataverse n′est pas conçu pour un traitement itératif.

Dans ces scénarios, un service distinct peut être utilisé pour héberger le processus long, dirigeant des demandes transactionnelles plus courtes vers Dataverse lui-même. Par exemple, l′utilisation de Flow ou l′hébergement de Microsoft SQL Server Integration Services (SSIS) ailleurs, puis l′orientation de demandes de création ou de mise à jour individuelles vers Dataverse est un modèle préférable que l′utilisation d′un plug-in pour effectuer une boucle via des milliers d′enregistrement en cours de création dans Dataverse.

Il est important de connaître et de comprendre les contraintes de la plateforme qui existent, afin de les autoriser dans votre conception d′application. En outre, si vous rencontrez ces erreurs, vous pouvez comprendre pourquoi elles se produisent et ce que vous pouvez changer pour les éviter.

Contrainte	Description
Délais d′expiration de plug-in	• Les plug-ins expirent au bout de 2 minutes. • N′exécutez pas des opérations longues dans les plug-ins. Protège la plateforme et le service sandbox et finalement l′utilisateur d′une mauvaise expérience utilisateur
Délais d′expiration de SQL	• Les requêtes à SQL Server expirent généralement à 120 secondes, bien que dans certains cas, le délai d’expiration de la commande soit plus long • Protège des demandes longues • Assure la protection dans une organisation spécifique et sa base de données privée • Assure également la sécurité au niveau de votre serveur de base de données par rapport à une utilisation excessive des ressources de telles que des processeurs/mémoire
Limites du workflow	• Fonctionne selon une stratégie d′utilisation équitable • Aucune limite fixe spécifique, mais équilibrer les ressource entre plusieurs organisations • Si une demande est faible est une organisation peut tirer le meilleur parti de la capacité disponible. Lorsque la demande est élevée, les ressources et le débit sont partagés.
Nombre maximal de connexions simultanées	• Il existe un paramètre par défaut de plateforme d′une limite du pool de connexion de 100 connexions du pool de connexion au serveur web dans IIS à la base de données. Dataverse ne modifie pas cette valeur. • Si cela se produit, cela indique une erreur dans le système ; recherchez pourquoi autant de connexions se bloquent. • Avec plusieurs serveurs web, chacun avec 100 connexions simultanées à la base de données de < 10 ms habituellement, cela suggère un débit de > 10 000 demandes à la base de données pour chaque serveur web. Cela ne doit pas être obligatoire et pourrait entraîner d′autres problèmes bien avant cela
ExecuteMultiple	• Le message ExecuteMultiple est conçu pour aider à envoyer des collections d′opérations à Dataverse depuis une source externe. • Le traitement de grands groupes de ces demandes peut engager des ressources vitales dans Dataverse au détriment d′un plus grand nombre de demandes critiques de réponse par les utilisateurs.
Limites de protection des services	• Pour garantir une disponibilité et des performances cohérentes pour tout le monde, nous appliquons certaines limites à la façon dont les API sont utilisées. Ces limites sont conçues pour détecter lorsque les applications clientes font des demandes extraordinaires sur les ressources du serveur. • Plus d’informations : Limites de l’API de protection des services

Étapes suivantes

Pour comprendre comment les contraintes de plateforme sont appliquées, il est nécessaire de comprendre comment les transactions de base de données. Plus d′informations : Conception de personnalisation évolutive : transactions de base de données

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é).