Discussion :

[Vannessa Sindy]

Bonjour à tous , je travail sur une application asp.net mvc4 et nous rencontrons des problèmes de performances liés à entity framework ,

le problème est que : une requête sous linq avec des joitures est très lente(15s) même si elle renvoi que 10 lignes et la même requette executé directement sous sql server fait meme pas 1s , alors d'après mes analyses je constate que la lenteur est du l'ors de la phase compilation par ce que EF transforme tout les champs string utiliés dans mes clauses where de varchar=> nvarchar d'ou une conversion implicite derrière .
nous utilisons l'approche : database first.
je suis censé faire cela dans mon context :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
   protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Properties<string>()
 .Configure(s => s.HasMaxLength(200).HasColumnType("varchar"));
}

le pb est que en mode database first cette méthode n'est appelé qu'une seule fois et mis dans le cache pour les prochains appels ,du
coup cette methode ne sera jamais appelé et mon correctif ne sera jamais appliqué

mon correctif c'est genre de dire à entity framework de ne pas changer le type de mes colonnes en nvarchar , il doit garder
les meme type que j'ai en BDD c'est à dire varchar, en esperant que mon pb viendrais de l'a, j'ai egalement desactivez le lazy loading et
AutoDetectChangesEnabled set to false pour tester, mais cela na rien changé
Besoin de piste svp

[DotNetMatt]

Alors il faut deja clarifier certains points :
- Les types de donnees "varchar" et "nvarchar" n'existent qu'au sein de SQL Server. Du cote applicatif donc C# les 2 sont equivalent au type de donnees "string". Donc ton problem ne vient vraisemblablement pas d'une convertion.
- La methode OnModelCreating n'est appellee que lorsque tu lances la commande Update-Database, donc a priori cela n'a rien a voir avec le souci de performance.

A l'aide de SQL Server Profiler, as-tu deja intercepte la requete SQL generee par Entity Framework ?
Si oui, tu peux la comparer avec celle que tu lances a la main, directement sur SQL Server. Ont-elles la meme tete ? Probablement pas.

A partir de la, tu pourras te rapprocher de ta requete manuelle en optimisant ta syntaxe LinQ pour que la requete generee soit similaire.

[EDIT]
Tu peux aussi comparer les plans d'execution des 2 requites (la generee par EF, et la manuelle) pour voir ce qui prend du temps.

[Pol63]

problèmes de performances liés à entity Framework

c'est souvent un pléonasme ...

[DotNetMatt]

Effectivement Pol63

[Vannessa Sindy]

Bonjour, merci, pour vos interventions, effectivement après des analyses encore très poussé, je me rends compte que le problème n'est pas effectivement lié aux conversions implites du type varchar à Nvarchar comme tu là bien dit DotnetMatt mais ce pb est quand même connus sur EF. L’un des problèmes que j'ai identifié était lié à une montée en charge du cpu via une méthode qui gênerait une fuite mémoire à cause du volume de données trop élevé pour la méthode lié. Et j'ai aussi optimisé certaine requête qui gênerais des plans parallèles du coup très couteux.
Remarque : j’ai gagné pas mal de temps en créant les index nécessaires, par contre , je constate trop de trafic réseau envoyé à SQL server qui me semble pas utiles comme par exemple : l’exécution d’un simple select sur un champs avec linq to entitie cela envoi au moins 80 lignes de notifications à sql server d’après le profiler, alors la plus part des notifications envoyé est ça par exemple : déclare @varbinary(7000), je me demandais si en désactivant l’envoi de ses notifications à SQL si cela pourrais m’aider à gagner du temps dans mes requetes linq de façon glabale et en même ça réduirais le trafic réseau il me semble . J’ai essayé : de désactiver : AutoDetectChangesEnabled set to false pour uniquement mes opérations de select , mais cela n’a rien changé,

[DotNetMatt]

SQL Server peut gerer un volume enorme de transactions, le NASDAQ par exemple gere plusieurs milliards de transactions par jour. Idem chez Microsoft avec toute la telemetrie par exemple. Bien sur ils ont une infrastructure adaptee, mais c'est pour donner un ordre d'idee...

Je ne pense pas que la solution a ton probleme soit dans les options peripheriques d'EF.
Je pense que ton probleme vient de la facon dont tu as formule ta requete LinQ. Il faut la repenser de telle sorte qu'en sortie tu obtiennes une requete proche de celle que tu lances a la main.

[Vannessa Sindy]

SQL Server peut gerer un volume enorme de transactions, le NASDAQ par exemple gere plusieurs milliards de transactions par jour. Idem chez Microsoft avec toute la telemetrie par exemple. Bien sur ils ont une infrastructure adaptee, mais c'est pour donner un ordre d'idee...

Je ne pense pas que la solution a ton probleme soit dans les options peripheriques d'EF.
Je pense que ton probleme vient de la facon dont tu as formule ta requete LinQ. Il faut la repenser de telle sorte qu'en sortie tu obtiennes une requete proche de celle que tu lances a la main.

Oui effectivement mon problème n'est pas lié est fonctionnement interne EF comme je le croyais , l'un des problème était du fait que mes requête linq

gêneraient des plan parèlles dans le plan d'exécution,