Optimiser les performances des opérations en bloc

Lorsque vous devez créer ou mettre à jour des milliers ou des millions d’enregistrements dans Dataverse, les choix que vous effectuez peuvent gagner du temps pour que le projet d’opération en bloc se termine. Cet article décrit les facteurs qui affectent les performances et les options dont vous avez besoin pour générer des applications clientes qui optimisent les performances pour les opérations en bloc. Vous devez également tenir compte d’autres facteurs, tels que le nombre d’enregistrements, la taille des enregistrements, la latence réseau et la complexité des données.

Type de table

Le type de table que vous choisissez de stocker vos données a le plus d’impact sur la quantité de débit attendue avec 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 des fonctionnalités plus importantes pour la modélisation des relations.
• Une table élastique stocke des données à l’aide d’Azure Cosmos DB. Les tables élastiques sont automatiquement mises à l’échelle horizontalement pour gérer de grandes quantités de données et des niveaux élevés de débit avec une faible latence. Les tables élastiques conviennent aux applications qui ont des charges de travail imprévisibles, irrégulières 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 des 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 inscrits pour s’exécuter de manière synchrone avant ou dans 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’existe aucune transaction. Toute erreur qui se produit dans le code du plug-in pendant 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-ins peut délibérément lever une exception pour annuler l’opération afin de s’assurer que la logique de validation des données est appliquée.

Tout plug-in inscrit 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 pour s’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 que vous avez sont limités dans la logique qu'ils tentent de réaliser. Bien que les plug-ins doivent se terminer dans un délai généreux de 2 minutes, les plug-ins synchrones qui prennent plus de deux secondes à s'exécuter dégradent sérieusement les performances.
• Assurez-vous que les plug-ins s’exécutent uniquement si 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 effectuer une logique aussi efficacement que possible. Pour les tables standard, vous devez prendre en compte l’impact que les transactions et les verrous d’enregistrement peuvent avoir sur les performances. En savoir plus sur la conception de personnalisation évolutive et d’autres bonnes pratiques pour l’écriture de plug-ins
• Choisissez l’API sur laquelle inscrire votre plug-in. Vous pouvez appliquer une logique synchrone pour s’exécuter sur les API d’opération en bloc plus efficaces CreateMultiple et UpdateMultiple. 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 inscrits pour les opérations de création ou de mise à jour afin d’améliorer les performances. Si la logique métier n’est pas essentielle ou si vous planifiez d’autres étapes pour garantir la cohérence des données éventuelle, vous pouvez désactiver manuellement les étapes de plug-in et les réactiver lorsque le projet d’opération en bloc est terminé. Toutefois, la désactivation des plug-ins désactive l’application de la logique à partir de n’importe quel client. Tout utilisateur ou autre processus ajoutant des données à Dataverse pendant cette période n’a pas de logique métier appliquée.

En tant que développeur d’une application cliente effectuant une opération massive, vous pouvez appliquer un paramètre facultatif aux demandes que vous envoyez pour contourner la logique. Seul un administrateur système ou des utilisateurs disposant 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ération en bloc

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

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

• Actuellement non disponible pour toutes les tables. Toute table personnalisée doit les prendre en charge, mais pas toutes les tables Dataverse principales les prennent en charge, telles que 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 pas pardonner des 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 sein d’une opération dans ces API entraîne l’échec de l’opération entière.
• Non pris en charge pour l’utilisation des 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 retourner des informations sur les opérations individuelles qui échouent. En savoir plus sur les opérations en bloc avec des tables élastiques.

APIs par lot

Si vous n’êtes pas en mesure d’utiliser des API d’opération en bloc, avec le Kit de développement logiciel (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 dans une requête unique et améliorer l’efficacité principalement en raison de moins de demandes plus volumineuses réduisant la charge utile totale envoyée et reçue sur le câble pour chaque opération. Une application cliente n’a pas besoin d’attendre la fin d’une opération avant d’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 pas d’efficacité améliorée 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 demande, mais pour de meilleurs résultats, nous vous recommandons de commencer par un nombre plus petit et d’expérimenter pour déterminer la taille du lot qui convient le mieux à votre cas.

Architecture du client

Dataverse est conçu comme 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 pour utiliser les forces de Dataverse.

Les goulots d’étranglement dans le code côté client sont la principale cause des problèmes de performances. Les développeurs ne parviennent souvent pas à utiliser entièrement les fonctionnalités du code, ce qui peut affecter les performances. Il est essentiel d’optimiser la façon dont l’application cliente utilise les cœurs ou le 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, telles que l’implémentation de la mise à l’échelle automatique, l’utilisation d’instances de préchauffage, l’ajustement de l’utilisation du processeur, l’utilisation de plusieurs cœurs et l’autorisation de la concurrence.

Limites de protection du service

Pour garantir une disponibilité et des performances cohérentes pour tous, Dataverse applique certaines limites à l’utilisation des API. Ces limites sont conçues pour détecter quand les applications clientes font des demandes extraordinaires sur les ressources 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 pas d’erreurs de limite de protection du service, vous n’avez pas agrandi la capacité de votre application.

Les erreurs de limite de protection des services sont simplement un autre type d’erreur temporaire que votre client doit être prêt à gérer, comme une perte temporaire de 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 des services vous indiquent combien de temps vous devez attendre avant de réessayer.

Lisez ces articles pour en savoir plus :

• Comment réessayer des requêtes Dataverse
• Limites de protection du service Dataverse
• Bonnes pratiques Azure : gestion des erreurs temporaires

Demandes 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 les mêmes

Chaque environnement Dataverse n’a pas le même nombre de ressources de serveur web qui lui sont allouées. Dataverse s’adapte au besoin de l’environnement en ajoutant d’autres ressources de serveur web pour la prendre en charge. Un environnement de production prenant en charge des milliers d’utilisateurs actifs nécessite plus de serveurs web qu’un environnement d’évaluation. Lorsque votre environnement a beaucoup de serveurs web, l’envoi de requêtes en parallèle peut faire une différence considérable dans le débit total que votre application cliente peut obtenir.

Degré de parallélisation recommandé (DOP)

Dataverse retourne des données dans un en-tête de réponse qui vous indique un degré de parallélisation (DOP) recommandé pour votre environnement. Les performances s’aggravent si vous envoyez plus de demandes parallèles que l’en-tête de réponse recommande. Le matériel client que vous utilisez pour exécuter votre application peut avoir besoin de cœurs d’UC supplémentaires pour envoyer ces nombreuses requêtes en parallèle. Vous devrez peut-être utiliser davantage de clients pour obtenir un débit maximal. Par exemple, vous pouvez utiliser un service d’application avec montée en charge ou une fonction Azure.

Selon votre architecture côté client, vous devrez peut-être fractionner le degré de parallélisme recommandé. Par exemple, lorsque vous avez deux clients et que votre DOP recommandé est 50 ; configurez chaque client pour qu’il utilise 25.

Désactiver l’affinité Azure

Le cas échéant, vous pouvez voir les 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 seul serveur web. La désactivation de l’affinité Azure n’est pas appropriée pour les applications interactives qui utilisent des données mises en cache du serveur pour optimiser l’expérience utilisateur.

Optimiser votre connexion

Lorsque vous utilisez .NET, vous devez appliquer des modifications de configuration comme les suivantes pour optimiser votre connexion afin que vos demandes ne soient pas limitées 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

En fonction des facteurs décrits précédemment, suivez ces recommandations pour optimiser le débit pour les projets d’opération en bloc :

• Choisissez un type de tableau qui répond à vos besoins. Les tables élastiques ont beaucoup plus de capacité pour les opérations en bloc.
• Réduisez, désactivez ou ignorez 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.
• Utilisez les API d’opération en bloc Dataverse lorsque vous pouvez, sinon utiliser des API de traitement par lots.
• Concevez votre application cliente pour gérer les erreurs temporaires, y compris celles retournées par les limites de protection du service.
• Envoyer des demandes en parallèle. Utilisez l’en-tête de réponse pour vous guider vers le degré de parallélisme recommandé (DOP). Désactivez le cookie d’affinité le cas échéant.
• Validez les données pour vous assurer qu’elles répondent au schéma de colonne de table. Cela permet d’éviter les erreurs et de réduire le nombre d’opérations ayant échoué.

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