DbContext ChangeTracking nuit aux performances ?

Question

Je suis en train de mettre à jour une application de EF1 à EF4.1. J'ai créé un DbContext et un ensemble de POCOs en utilisant les modèles "ADO.NET DbContext Generator".

Lorsque j'interroge le DbContext généré, la partie base de données de la requête prend 4ms pour s'exécuter (validé avec EF Profiler). Ensuite, le contexte prend environ 40 secondes (en mots : QUATRE !) pour faire ce qu'il fait avant de retourner le résultat à l'application.

EF1 traite la même requête en moins de 2 secondes.

En désactivant AutoDetectChanges, LazyLoading et ProxyGeneration, je gagne 2 à 3 secondes.

Lorsque j'utilise la méthode d'extension AsNoTracking(), je suis en mesure de réduire le temps d'exécution total à environ 3 secondes.

Cela indique que ChangeTracking est le coupable.

Mais ChangeTracking est ce dont j'ai besoin. Je dois être capable de faire persister tous les changements sans avoir à trier les entités modifiées.

Avez-vous une idée de la façon dont je pourrais résoudre ce problème de performance ?

Answer 1

Est-ce que la technique à la fin de cette documentation utile ? Par ailleurs, j'ai évité bon nombre des écueils liés aux performances en utilisant une interface fluide pour déclarer quelles entités d'une transaction donnée ne changeront certainement pas ou pourraient changer (immuables ou immuables). Par exemple, si les entités que je sauvegarde sont des racines agrégées dans lesquelles la racine ou ses entités font référence à des éléments "refdata", cette heuristique permet d'éviter de nombreuses écritures car les éléments immuables n'ont pas besoin d'être suivis . Les éléments mutables sont tous écrits sans contrôle (une faiblesse... qui peut ou non être acceptable).

Je l'utilise avec un modèle de référentiel générique précisément parce que je ne veux pas suivre les changements ou mettre en œuvre une stratégie spécifique pour chaque cas. Si cela n'est pas suffisant, vous pouvez peut-être mettre en place votre propre suivi des changements en dehors du contexte et ajouter des entités si nécessaire.

Answer 2

Sans voir la requête, je ne peux pas dire avec certitude quel est le problème. Cela pourrait-il être lié ?

Pourquoi l'opérateur Contains() dégrade-t-il si fortement les performances d'Entity Framework ?

En fonction des opérateurs LINQ utilisés, il semble que EF ait du mal à convertir certaines requêtes en SQL. Peut-être rencontrez-vous une situation similaire ici.