Optimiser les performances pour les opérations en bloc

Article
07/01/2024

Lorsque vous devez créer ou mettre à jour des milliers ou des millions d’enregistrements dans Dataverse, les choix que vous faites peuvent vous faire gagner des heures pour terminer le projet d’opérations en bloc. Cet article décrit les facteurs qui affectent les performances et les options disponibles pour créer des applications clientes qui optimisent les performances pour les opérations en bloc. Il convient également de prendre en compte d’autres facteurs, tels que le nombre d’enregistrements, la taille des enregistrements, la latence du réseau et la complexité des données.

Type de table

Le type de table que vous choisissez pour stocker vos données a le plus grand impact sur le débit auquel vous pouvez vous attendre pour les opérations en bloc. Dataverse offre deux types de tables : standard et élastique.

Une table standard stocke les données à l’aide d’Azure SQL. Les tables standard fournissent une prise en charge des transactions et de plus grandes capacités pour la modélisation des relations.
Une table élastique stocke les données à l’aide d’Azure Cosmos DB. Les tables élastiques évoluent automatiquement horizontalement pour gérer de grandes quantités de données et des niveaux de débit élevés avec une faible latence. Les tables élastiques conviennent aux applications ayant des charges de travail imprévisibles, sporadiques ou en croissance rapide.

Si les temps de chargement des données sont votre principale préoccupation, les tables élastiques offrent les meilleures performances. Découvrez quand utiliser les tables élastiques

Logique métier

Dataverse offre la possibilité d’ajouter une logique métier supplémentaire lorsque des enregistrements sont créés ou mis à jour à l’aide de plug-ins. Les Plug-ins peuvent être enregistrés pour s’exécuter de manière synchrone avant ou pendant la transaction d’une opération de table standard. Les tables élastiques prennent en charge les plug-ins qui peuvent s’exécuter avant le démarrage d’une opération, car il n’y a aucune transaction. Toute erreur qui se produit dans le code du plug-in lors d’une étape synchrone pour une table standard, ou avant l’opération dans une table élastique, annule l’opération. Un développeur de plug-in peut délibérément déclencher une exception pour annuler l’opération afin de garantir que la logique de validation des données est appliquée.

Tout plug-in enregistré pour s’exécuter de manière synchrone augmente le temps nécessaire à l’exécution de l’opération. Pour préserver les performances :

Limitez le nombre de plug-ins synchrones enregistrés pour les opérations. Ajoutez une logique à exécuter de manière asynchrone à l’aide d’un plug-in asynchrone ou d’un flux Power Automate, sauf s’il est essentiel que la logique soit appliquée de manière synchrone.
Assurez-vous que les plug-ins disponibles sont limités dans la logique qu’ils tentent d’exécuter. Alors que les plug-ins doivent s’exécuter dans une limite généreuse de 2 minutes, les plug-ins synchrones qui mettent plus de deux secondes à s’exécuter dégradent considérablement les performances.
Assurez-vous que les plug-ins ne s’exécutent que lorsque cela est nécessaire. Les plug-ins pour les opérations de mise à jour peuvent être filtrés pour s’exécuter uniquement lorsque des colonnes spécifiques sont mises à jour.
Assurez-vous que les plug-ins sont optimisés pour exécuter la logique aussi efficacement que possible. Pour les tables standard, vous devez prendre en compte l’impact que les transactions et les verrouillages d’enregistrement peuvent avoir sur les performances. En savoir plus sur la conception de personnalisation évolutive et les autres pratiques recommandées pour écrire des plug-ins
Choisissez sur quelle API enregistrer votre plug-in. Vous pouvez appliquer une logique synchrone à exécuter sur les API d’opérations en bloc CreateMultiple et UpdateMultiple plus efficaces. Découvrez comment écrire des plug-ins pour CreateMultiple et UpdateMultiple.

Contourner la logique métier

Pour accélérer le projet d’opération en bloc, vous pouvez désactiver les plug-ins enregistrés pour les opérations de création et de mise à jour pour améliorer les performances. Si la logique métier n’est pas essentielle ou si vous prévoyez d’autres étapes pour garantir une éventuelle cohérence des données, vous pouvez désactiver manuellement les étapes du plug-in et les réactiver une fois le projet d’opérations en bloc terminé. Cependant, la désactivation des plug-ins empêche l’application de la logique à partir de n’importe quel client. Tout utilisateur ou autre processus qui ajoute des données à Dataverse sur cette période n’a aucune logique métier appliquée.

En tant que développeur d’une application cliente qui exécute l’opération en bloc, vous pouvez appliquer un paramètre facultatif aux requêtes que vous envoyez pour contourner la logique. Seul un administrateur système ou des utilisateurs qui disposent d’un privilège spécifique peuvent utiliser cet en-tête. En savoir plus sur la façon de contourner la logique Dataverse personnalisée.

API d’opérations en bloc

Dataverse fournit des API d’opérations en bloc qui offrent le débit le plus élevé possible pour les opérations de création et de mise à jour. Ces API incluent CreateMultiple, UpdateMultiple et UpsertMultiple. Pour les tables élastiques uniquement, vous pouvez utiliser DeleteMultiple.

Bien que ces API offrent le débit le plus élevé, elles présentent les limitations suivantes pour les tables standard :

Ne sont pas disponibles actuellement pour toutes les tables. Toute table personnalisée devrait les prendre en charge, mais toutes les tables Dataverse principales ne les prennent pas en charge, comme la table Compte ou Contact. Vous pouvez exécuter une requête fournie dans la documentation pour déterminer si une table peut utiliser ces API.
Ne pardonnent pas les erreurs de données. Vous devez vous assurer que les données que vous modifiez sont soigneusement nettoyées et validées. Toute erreur qui se produit au cours d’une opération dans ces API entraîne l’échec de toute l’opération.
Ne sont pas prises en charge pour une utilisation dans les plug-ins. Actuellement, ces API ne doivent être utilisées que par des applications clientes externes.

Les opérations en bloc sont disponibles pour toutes les tables élastiques et les tables élastiques peuvent renvoyer des informations sur les opérations individuelles qui échouent. En savoir plus sur les opérations en bloc avec les tables élastiques.

API par lots

Si vous ne pouvez pas utiliser les API d’opérations en bloc, avec le SDK pour .NET, vous pouvez utiliser ExecuteMultiple, et avec l’API Web, vous pouvez utiliser OData $batch.

Utilisez ces API pour regrouper un ensemble d’opérations en une seule requête et obtenir une plus grande efficacité, principalement en raison de requêtes moins nombreuses et plus volumineuses qui réduisent la charge utile totale envoyée et reçue par câble pour chaque opération. Une application cliente n’a pas besoin d’attendre la fin d’une opération pour envoyer la requête suivante.

Chaque opération au sein de la requête est appliquée de manière séquentielle sur le serveur, il n’y a donc aucune amélioration de l’efficacité par opération. Toutefois, étant donné que les opérations sont effectuées individuellement, vous pouvez obtenir des informations sur les opérations qui ont échoué, ou arrêter le lot lorsqu’une erreur se produit. Vous pouvez envoyer jusqu’à 1 000 opérations par requête, mais pour optimiser les résultats, nous vous recommandons de commencer avec un nombre plus petit et d’expérimenter pour déterminer quelle taille de lot convient le mieux à votre cas.

Notes

Les API d’opérations en bloc et par lots ont des gains de performances significatifs lorsqu’elles sont utilisées en parallèle. Voir Requêtes parallèles.

Architecture du client

Dataverse est conçu comme une source de données pour prendre en charge plusieurs applications avec un grand nombre d’utilisateurs simultanés. Pour optimiser le débit, concevez votre client de manière à utiliser les points forts de Dataverse.

Les goulots d’étranglement dans le code côté client sont la principale cause des problèmes de performances. Souvent, les développeurs ne tirent pas pleinement parti des capacités du code, ce qui peut affecter les performances. Il est crucial d’optimiser la manière dont l’application cliente utilise les cœurs ou la fonction de calcul de l’infrastructure, car l’échec de l’optimisation peut affecter considérablement les performances. Par exemple, lors de l’utilisation d’Azure Functions, plusieurs étapes peuvent être effectuées pour optimiser les performances, comme l’implémentation de la mise à l’échelle automatique, l’utilisation d’instances de préparation, l’ajustement de l’utilisation du processeur, l’utilisation de plusieurs cœurs et l’autorisation de la simultanéité.

Limites de protection du service

Pour garantir une disponibilité et des performances cohérentes pour tous, Dataverse applique 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. Les projets d’opérations en bloc ont toujours des exigences extraordinaires, vous devez donc être prêt à gérer les erreurs renvoyées par les limites de protection du service. Si vous n’obtenez aucune erreur de limite de protection du service, vous n’avez pas optimisé les capacités de votre application.

Les erreurs de limite de protection du service ne sont qu’un autre type d’erreur temporaire que votre client doit être prêt à gérer, comme une perte temporaire de la connectivité réseau. Une application cliente résiliente doit répondre à l’erreur en attendant et en réessayant. La seule différence est que les limites de protection du service vous indiquent combien de temps vous devez attendre avant de réessayer.

Lisez ces articles pour en savoir plus :

Requêtes parallèles

Vous pouvez voir une amélioration significative du débit en envoyant des requêtes en parallèle, mais vous devez comprendre comment les envoyer correctement.

Tous les environnements ne sont pas identiques

Tous les environnements Dataverse ne se voient pas attribuer le même nombre de ressources de serveur Web. Dataverse s’adapte aux besoins de l’environnement en ajoutant plus de ressources de serveur Web pour le prendre en charge. Un environnement de production qui prend en charge des milliers d’utilisateurs actifs nécessite plus de serveurs Web qu’un environnement d’essai. Lorsque votre environnement a beaucoup de serveurs Web, l’envoi de requêtes en parallèle peut faire une grande différence dans le débit total que votre application client peut atteindre.

Degré de parallélisme recommandé (DOP)

Dataverse renvoie des données dans un en-tête de réponse qui vous indique un degré de parallélisme (DOP) recommandé pour votre environnement. Les performances se dégradent si vous envoyez plus de requêtes parallèles que ce que recommande l’en-tête de réponse. Le matériel client que vous utilisez pour exécuter votre application peut avoir besoin de plus de cœurs de processeur pour envoyer autant de requêtes en parallèle. Vous devrez peut-être utiliser plus de clients pour obtenir un débit maximal. Par exemple, vous pouvez utiliser un service d’application évolutif ou une fonction Azure.

En fonction de votre architecture côté client, vous devrez peut-être diviser le degré de parallélisme recommandé. Par exemple, lorsque vous avez deux clients et que votre DOP recommandé est de 50, configurez chaque client pour utiliser 25.

Désactiver l’affinité Azure

Le cas échéant, vous pouvez obtenir de meilleurs résultats lorsque vous configurez votre client pour utiliser tous les serveurs Web disponibles en supprimant le cookie d’affinité Azure qui tente d’associer votre application à un serveur Web unique. La désactivation de l’affinité Azure n’est pas appropriée pour les applications interactives qui utilisent les données mises en cache du serveur pour optimiser l’expérience utilisateur.

Optimiser votre connexion

Lorsque vous utilisez .NET, vous devez appliquer les modifications de configuration suivantes pour optimiser votre connexion afin que vos requêtes ne soient pas limitées par les paramètres par défaut.

// Bump up the min threads reserved for this app to ramp connections faster - minWorkerThreads defaults to 4, minIOCP defaults to 4 
ThreadPool.SetMinThreads(100, 100);
// Change max connections from .NET to a remote service default: 2
System.Net.ServicePointManager.DefaultConnectionLimit = 65000;
// Turn off the Expect 100 to continue message - 'true' will cause the caller to wait until it round-trip confirms a connection to the server 
System.Net.ServicePointManager.Expect100Continue = false;
// Can decrease overall transmission overhead but can cause delay in data packet arrival
System.Net.ServicePointManager.UseNagleAlgorithm = false;

Résumé des recommandations

Sur la base des facteurs décrits précédemment, suivez ces recommandations pour optimiser le débit des projets d’opérations en bloc :

Choisissez un type de table qui correspond à vos exigences. Les tables élastiques ont une capacité bien plus grande pour les opérations en bloc.
Réduisez, désactivez ou contournez la logique métier personnalisée sur les tables que vous utilisez. Configurez votre application cliente pour contourner la logique personnalisée, le cas échéant.
Utiliser les API d’opérations en bloc Dataverse si possible, sinon utilisez les API par lots.
Concevez votre application cliente pour gérer les erreurs temporaires, y compris les erreurs renvoyées par les limites de protection du service.
Envoyez des requêtes en parallèle. Utilisez l’en-tête de réponse pour vous guider vers le degré de parallélisme (DOP) recommandé. Désactivez le cookie d’affinité, le cas échéant.
Validez les données pour garantir qu’elles correspondent au schéma des colonnes de table. Cela peut aider à prévenir les erreurs et à réduire le nombre d’opérations en échec.

Voir aussi

Tableaux élastiques
Utiliser des plug-ins pour étendre les processus d’entreprise
Contourner la logique Dataverse personnalisée
Messages d’opération en bloc
Écrire des plug-ins pour CreateMultiple et UpdateMultiple
Envoyer des demandes parallèles