Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Candidat au Club
    Femme Profil pro
    Architecte réseau
    Inscrit en
    septembre 2014
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Architecte réseau
    Secteur : Finance

    Informations forums :
    Inscription : septembre 2014
    Messages : 4
    Points : 4
    Points
    4

    Par défaut entity framework performances transformation type varchar à nvarchar

    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

  2. #2
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    février 2010
    Messages
    3 487
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : février 2010
    Messages : 3 487
    Points : 9 728
    Points
    9 728
    Billets dans le blog
    3

    Par défaut

    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.
    Less Is More
    Pensez à utiliser les boutons , et les balises code
    Desole pour l'absence d'accents, clavier US oblige
    Celui qui pense qu'un professionnel coute cher n'a aucune idee de ce que peut lui couter un incompetent.

  3. #3
    Expert éminent sénior Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    avril 2007
    Messages
    13 493
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : avril 2007
    Messages : 13 493
    Points : 24 198
    Points
    24 198

    Par défaut

    Citation Envoyé par Vannessa Sindy Voir le message
    problèmes de performances liés à entity Framework
    c'est souvent un pléonasme ...
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  4. #4
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    février 2010
    Messages
    3 487
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : février 2010
    Messages : 3 487
    Points : 9 728
    Points
    9 728
    Billets dans le blog
    3

    Par défaut

    Effectivement Pol63
    Less Is More
    Pensez à utiliser les boutons , et les balises code
    Desole pour l'absence d'accents, clavier US oblige
    Celui qui pense qu'un professionnel coute cher n'a aucune idee de ce que peut lui couter un incompetent.

  5. #5
    Candidat au Club
    Femme Profil pro
    Architecte réseau
    Inscrit en
    septembre 2014
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Architecte réseau
    Secteur : Finance

    Informations forums :
    Inscription : septembre 2014
    Messages : 4
    Points : 4
    Points
    4

    Par défaut

    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é,

  6. #6
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    février 2010
    Messages
    3 487
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : février 2010
    Messages : 3 487
    Points : 9 728
    Points
    9 728
    Billets dans le blog
    3

    Par défaut

    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.
    Less Is More
    Pensez à utiliser les boutons , et les balises code
    Desole pour l'absence d'accents, clavier US oblige
    Celui qui pense qu'un professionnel coute cher n'a aucune idee de ce que peut lui couter un incompetent.

  7. #7
    Candidat au Club
    Femme Profil pro
    Architecte réseau
    Inscrit en
    septembre 2014
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Architecte réseau
    Secteur : Finance

    Informations forums :
    Inscription : septembre 2014
    Messages : 4
    Points : 4
    Points
    4

    Par défaut

    Citation Envoyé par DotNetMatt Voir le message
    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,

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 61
    Dernier message: 19/09/2014, 09h51
  2. Le type "TimeSpan" et l'Entity Framework
    Par Fra212 dans le forum Entity Framework
    Réponses: 2
    Dernier message: 27/02/2012, 10h51
  3. [Entity Framework] Performances désastreuses sur la pagination
    Par kedare dans le forum Développement
    Réponses: 30
    Dernier message: 25/01/2011, 17h44
  4. Problème de type varchar nvarchar et sp_executesql
    Par mohamed301084 dans le forum MS SQL Server
    Réponses: 12
    Dernier message: 29/10/2010, 14h43
  5. Entity framework et enum type
    Par seb_asm dans le forum Framework .NET
    Réponses: 6
    Dernier message: 23/02/2009, 10h57

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo