3 : Problèmes de performances

Cette page traite des problèmes liés aux performances, notamment les délais d'expiration, la limitation du débit et la lenteur des opérations.

Limitation du débit API (HTTP 429)

Erreur : « HTTP 429 - Trop de requêtes » ou « Limite de protection du service dépassée »

Cause : vos requêtes dépassent les limites de débit de l'API Dataverse

Symptômes :

• Les opérations ralentissent considérablement

• Échecs sporadiques avec tentatives de réessai

• Messages d'erreur faisant référence à la « limitation » ou à la « limite de débit »

• Le processus s'interrompt ou s'inverse à mesure que les tentatives de réessai sont effectuées

Comprendre les limites de protection du service Dataverse :

Microsoft Dataverse applique des limites de protection du service afin de garantir la stabilité de la plateforme. Ces limites sont évaluées sur une fenêtre glissante de 5 minutes et comprennent :

• Nombre de requêtes : 6 000 requêtes par utilisateur par fenêtre de 5 minutes

• Temps d'exécution : 20 minutes (1 200 secondes) de temps d'exécution combiné par fenêtre de 5 minutes

• Demandes simultanées : 52 demandes simultanées par utilisateur

Lorsque l'une de ces limites est dépassée, Dataverse renvoie une erreur HTTP 429 et peut inclure un en-tête « Retry-After » indiquant le temps d'attente.

Solutions :

1. Passez au préréglage de performances « Rate Safe » (Sécurité de débit) ou « Conservative » (Conservateur)

2. Réduisez le nombre maximal d'entités simultanées à 2 ou moins

3. Réduisez la taille des lots à 100 ou moins

4. Exécutez les opérations pendant les heures creuses.

5. Attendez 5 minutes avant de réessayer : la fenêtre glissante sera réinitialisée

⚠ Important : si vous atteignez la limite de débit, vous devez attendre environ 5 minutes avant de réessayer. Si vous essayez de réessayer immédiatement, l'opération continuera d'échouer et la période de limitation pourrait être prolongée. La fenêtre glissante de 5 minutes signifie qu'au fil du temps, vos requêtes les plus anciennes « sortent » de la fenêtre, libérant ainsi de la capacité.

💡 Astuce : DvSchemaSync inclut une logique de réessai intégrée qui respecte les limites de débit. Cependant, si vous rencontrez régulièrement des ralentissements, réduisez vos paramètres de performance plutôt que de compter sur les réessais, car ceux-ci ralentissent le débit global.

Erreurs de délai d'expiration

Erreur : « Délai d'opération expiré » ou « Délai de requête dépassé »

Causes possibles :

• Tables très volumineuses dont la synchronisation prend trop de temps

• Problèmes de latence du réseau

• Environnement Dataverse soumis à une charge importante

Solutions :

1. Réduire la taille des lots afin de traiter moins d'enregistrements par requête

2. Synchroniser les tables individuellement plutôt que toutes en même temps

3. Exécuter pendant les heures creuses, lorsque l'environnement est moins sollicité

Lenteur des performances de synchronisation

Symptômes : les opérations de synchronisation prennent beaucoup plus de temps que prévu

Conseils d'optimisation :

1. Activez le traitement parallèle : traitez plusieurs entités simultanément

2. Augmentez la taille des lots : des lots plus importants réduisent la charge API (si vous ne dépassez pas les limites de débit).

3. Utilisez la copie en masse : abaissez le seuil de copie en masse pour les grandes tables

4. Synchronisation incrémentielle : après la synchronisation initiale, ne synchronisez que les enregistrements modifiés.

5. Vérifiez les ressources système : assurez-vous que la puissance du processeur, la mémoire et la bande passante réseau sont suffisantes

Problèmes de mémoire

Erreur : « Mémoire insuffisante » ou l'application ne répond plus

Cause : traitement de tables très volumineuses ou trop d'opérations simultanées

Solutions :

1. Réduisez la taille des lots afin d'utiliser moins de mémoire par opération

2. Réduisez le nombre maximal d'entités simultanées afin de réduire l'utilisation parallèle de la mémoire

3. Fermez les autres applications pour libérer de la mémoire système

4. Passez au préréglage Conservateur pour une utilisation minimale de la mémoire

Délais d'expiration de la pause automatique Azure SQL

Erreur : délai d'expiration de la connexion ou « La base de données est en pause » lors de la première tentative de synchronisation

Cause : les bases de données Azure SQL Serverless se mettent automatiquement en pause après une période d'inactivité afin de réduire les coûts. Lorsque DvSchemaSync tente de se connecter à une base de données en pause, Azure doit « réchauffer » la base de données avant de pouvoir accepter les connexions. Ce processus de réchauffement peut prendre entre 30 et 60 secondes, voire plus, ce qui peut dépasser le délai d'expiration de connexion par défaut.

Symptômes :

• La première tentative de connexion après une période d'inactivité échoue en raison d'un délai d'expiration

• Les tentatives de connexion suivantes aboutissent

• Le problème se reproduit après une période d'inactivité de la base de données (généralement 1 heure sans activité)

Solutions :

1. Réessayez la connexion : il suffit de réessayer la synchronisation après un bref délai — la base de données devrait être prête

2. Préchauffez la base de données : avant la synchronisation, testez la connexion dans la gestion des connexions pour réactiver la base de données

3. Ajustez le délai de pause automatique : dans Azure Portal, augmentez le délai de pause automatique ou désactivez-le pour les bases de données fréquemment utilisées

4. Planifiez une activité régulière : configurez une tâche planifiée pour interroger la base de données périodiquement afin d'éviter la mise en pause.

5. Passez au niveau Provisioned : si la pause automatique cause des problèmes fréquents, envisagez de passer du niveau Serverless au niveau Provisioned.

💡 Conseil : Azure SQL Serverless est rentable pour une utilisation intermittente, mais si vous exécutez des synchronisations planifiées ou avez besoin de temps de réponse constants, un niveau Provisioned peut être plus adapté.

Recommandations relatives aux niveaux Azure SQL

Le choix du niveau Azure SQL approprié dépend de votre volume de données, de la fréquence de synchronisation et des exigences en matière de performances. Les recommandations suivantes sont basées sur des charges de travail DvSchemaSync typiques :

Serverless vs. Provisioned Compute :

⚠ Important : il s'agit de recommandations générales. Vos besoins réels peuvent varier en fonction du nombre de tables synchronisées, du nombre d'enregistrements, de la fréquence de synchronisation et du nombre d'utilisateurs simultanés exécutant des rapports sur la base de données. Surveillez votre utilisation DTU/vCore dans Azure Portal et augmentez la capacité si vous dépassez régulièrement 80 % d'utilisation.