IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

Dotnet Discussion :

[Tutoriel] Mesure des performances de Linq face à Sql et Entity Framework


Sujet :

Dotnet

  1. #41
    Expert éminent sénior

    Avatar de Philippe Vialatte
    Homme Profil pro
    Architecte technique
    Inscrit en
    Juillet 2004
    Messages
    3 029
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Juillet 2004
    Messages : 3 029
    Points : 12 465
    Points
    12 465
    Par défaut
    Et bah moin, je vais pas répondre pareil, na (a noter, je n'utilises pas EF)

    Citation Envoyé par ddaime Voir le message
    Utilisez vous des PS (CRUD) pour chaque table ou bien attaquez vous directement les tables ?
    Dans 98% des cas, pour du CRUD sur une table simple, je ne passes pas par une SP.

    Forcément, cela s'accompagne de règles de "bonne conduite":
    - 5 à 10 requètes (max) de selection sur une page (sinon -> SP)
    - les lookups sont stockées en cache (même si j'ai des SP)
    - si il faut au moins 3 jointures -> SP
    - pas de code Linq dans les pages, comme ca, si necessaire, on peut repasser sur un autre mecanisme

    Après, soyons clair, sur les 6 derniers projets que j'ai utilisé, j'ai créé...8 procédures stockées, 6 pour utiliser des CTE et du paging, les 2 autres pour des requêtes complexes qui faisaient intervenir 7 ou tables.

    Rapport au client, la durée max d'affichage d'une page doit être de 3 secondes, dans le cas d'une page complexe (grille de 100 enregistrements, avec de l'AJAX, et autres), et elle doit tenir ce score avec > 100 requetes/secondes (tests de charge avant MEP)

    A noter, dans une page moyenne, le temps passé dans l'appel à SQL server compte pour moins de 10% du temps total.

    Mon Blog

    The Cake is still a lie !!!



    Vous voulez contribuer à la rubrique .NET ? Contactez-moi par MP.
    Vous voulez rédiger des articles pour la rubrique .NET ? Voici la procédure à suivre.

  2. #42
    Membre confirmé

    Profil pro
    Développeur .NET
    Inscrit en
    Août 2004
    Messages
    178
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Août 2004
    Messages : 178
    Points : 645
    Points
    645
    Par défaut
    Article très intéressant.

    Immobilis as-tu lu cet article ?

    http://labs.bewise.fr/Article/Entity...eur-aux-DBA--/

    Je le trouve assez en rapport avec ce que tu as fais, peut-être qu'il pourra t'apporter des infos en plus.

  3. #43
    Membre chevronné
    Profil pro
    Inscrit en
    Mars 2005
    Messages
    1 273
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2005
    Messages : 1 273
    Points : 2 202
    Points
    2 202
    Par défaut
    J'aime ce test parce qu'il prouve que le problème n'est pas l'ORM mais bien le fait d'utiliser un ORM en ignorant le SQL.

    En revanche, sur la lecture, je suis plus mitigé au sens où il est fort probable que l'écart soit du par le cache de context. En gros, c'est une fausse performance.

  4. #44
    Expert éminent
    Avatar de Immobilis
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mars 2004
    Messages
    6 559
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Mars 2004
    Messages : 6 559
    Points : 9 506
    Points
    9 506
    Par défaut
    Citation Envoyé par B.AF Voir le message
    En revanche, sur la lecture, je suis plus mitigé au sens où il est fort probable que l'écart soit du par le cache de context. En gros, c'est une fausse performance.
    Quel fournisseur exactement?

    Que ce soit avec Linq to SQL ou bien Linq to Entities, SQL Server Profiler indique que les requêtes sont systématiquement envoyées à la base. Le cache des contextes n'est pas employé à cette fin. Cela est précisé dans ce papier d'ailleurs: http://blogs.msdn.com/b/dinesh.kulka...l-caching.aspx
    LINQ to SQL was designed to get you objects from the database and to submit the changes back to the database. It is not intended to be a mid-tier caching component. It is not a cache and it does not pretend to be one.
    A+
    "Winter is coming" (ma nouvelle page d'accueil)

  5. #45
    Membre chevronné
    Profil pro
    Inscrit en
    Mars 2005
    Messages
    1 273
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2005
    Messages : 1 273
    Points : 2 202
    Points
    2 202
    Par défaut
    Linq to sql oui, mais pas EF. Merci pour la réponse en tous cas !

  6. #46
    Expert éminent
    Avatar de Immobilis
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mars 2004
    Messages
    6 559
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Mars 2004
    Messages : 6 559
    Points : 9 506
    Points
    9 506
    Par défaut
    Citation Envoyé par B.AF Voir le message
    Linq to sql oui, mais pas EF. Merci pour la réponse en tous cas !
    Est-ce que tu peux préciser ce que tu entends par "cache" de Entity Framework? Sauf erreur, Linq to Entities gardera la requête en mémoire mais pas son résultat. Les données seront totalement rechargées à la requête suivante. C'est la même chose pour du SQL "natif".
    "Winter is coming" (ma nouvelle page d'accueil)

  7. #47
    Membre expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Novembre 2004
    Messages
    1 795
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2004
    Messages : 1 795
    Points : 3 173
    Points
    3 173
    Par défaut
    noter, dans une page moyenne, le temps passé dans l'appel à SQL server compte pour moins de 10% du temps total.
    Idéalement oui la moyennes de ce que j'ai vu sur trois projets différents ces 4 dernières années c'est plutôt 75 à 80% avant optimisation...
    Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
    MCTS Database Development
    MCTS Database Administration

  8. #48
    Expert éminent sénior

    Avatar de Philippe Vialatte
    Homme Profil pro
    Architecte technique
    Inscrit en
    Juillet 2004
    Messages
    3 029
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Juillet 2004
    Messages : 3 029
    Points : 12 465
    Points
    12 465
    Par défaut
    Citation Envoyé par iberserk Voir le message
    Idéalement oui la moyennes de ce que j'ai vu sur trois projets différents ces 4 dernières années c'est plutôt 75 à 80% avant optimisation...
    CF l'autre post dans l'autre discussion, avant la mise en prod, et en cours de dev, toujours avoir le nez dans les logs de sql server, ORM ou pas

    Mon Blog

    The Cake is still a lie !!!



    Vous voulez contribuer à la rubrique .NET ? Contactez-moi par MP.
    Vous voulez rédiger des articles pour la rubrique .NET ? Voici la procédure à suivre.

  9. #49
    Expert éminent
    Avatar de Immobilis
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mars 2004
    Messages
    6 559
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Mars 2004
    Messages : 6 559
    Points : 9 506
    Points
    9 506
    Par défaut
    Pour information, je viens de tomber sur ceci Local Database Overview for Windows Phone qui indique que c'est Linq To SQL qui est supporté par les téléphones Windows 7.1.

    Linq to Sql est encore à suivre.

    A+
    "Winter is coming" (ma nouvelle page d'accueil)

  10. #50
    Expert éminent
    Avatar de Immobilis
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mars 2004
    Messages
    6 559
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Mars 2004
    Messages : 6 559
    Points : 9 506
    Points
    9 506
    Par défaut Comparaison pour l'affichage d'un GridView
    Salut,

    Histoire d'apporter un peu d'eau au moulin, par curiosité j'ai comparé les requêtes générées par le Framework lors de l'affichage de trois GridView. Chacun est connecté à une DataSource native, je n'ai fait qu'utiliser les assistants.
    • Le premier est connecté à un SqlDataSource;
    • Le deuxième à une EntityDataSource;
    • Le troisième à une LinqDataSource.
    Les requêtes pour afficher la page 8 sont dans l'ordre:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    SELECT * FROM [Table_1]
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    SELECT COUNT(*) AS [value]
    FROM [dbo].[Table_1] AS [t0]
     
    SELECT TOP (10) 
    [Extent1].[Guid] AS [Guid], 
    [Extent1].[TestField] AS [TestField]
    FROM ( SELECT [Extent1].[Guid] AS [Guid], [Extent1].[TestField] AS [TestField], row_number() OVER (ORDER BY [Extent1].[Guid] ASC) AS [row_number]
    	FROM [dbo].[Table_1] AS [Extent1]
    )  AS [Extent1]
    WHERE [Extent1].[row_number] > 70
    ORDER BY [Extent1].[Guid] ASC
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    SELECT COUNT(*) AS [value]
    FROM [dbo].[Table_1] AS [t0]
     
    exec sp_executesql N'SELECT [t1].[Guid], [t1].[TestField]
    FROM (
        SELECT ROW_NUMBER() OVER (ORDER BY [t0].[Guid], [t0].[TestField]) AS [ROW_NUMBER], [t0].[Guid], [t0].[TestField]
        FROM [dbo].[Table_1] AS [t0]
        ) AS [t1]
    WHERE [t1].[ROW_NUMBER] BETWEEN @p0 + 1 AND @p0 + @p1
    ORDER BY [t1].[ROW_NUMBER]',N'@p0 int,@p1 int',@p0=70,@p1=10
    Evidemment la SqlDataSource perd car elle ramène toute la table. Que pense les DBA des deux autres sources?

    A+
    "Winter is coming" (ma nouvelle page d'accueil)

  11. #51
    Membre expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Novembre 2004
    Messages
    1 795
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2004
    Messages : 1 795
    Points : 3 173
    Points
    3 173
    Par défaut
    A priori tes deux derniers gridview sont paginés d'ou les requêtes utilisant des fonctions de fenêtrage ainsi qu'un COUNT global permettant de gérer les nombre de page.

    Amusant le changement de requête entre ENTITY et LINQTOSQL... même si elles donnent exactement le même résultat (page 8 avec pagesize à 10...).

    Le premier gridview est paginé?
    Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
    MCTS Database Development
    MCTS Database Administration

  12. #52
    Expert éminent
    Avatar de Immobilis
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mars 2004
    Messages
    6 559
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Mars 2004
    Messages : 6 559
    Points : 9 506
    Points
    9 506
    Par défaut
    Citation Envoyé par iberserk Voir le message
    Le premier gridview est paginé?
    Oui
    "Winter is coming" (ma nouvelle page d'accueil)

  13. #53
    Invité
    Invité(e)
    Par défaut
    Juste pour ajouter un lien intéressant => voir ici.

  14. #54
    Expert éminent
    Avatar de Immobilis
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mars 2004
    Messages
    6 559
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Mars 2004
    Messages : 6 559
    Points : 9 506
    Points
    9 506
    Par défaut
    Re salut,

    En dehors de performances intrinsèques de EF, voici un lien vers un papier au sujet de la génération des requêtes: http://labs.bewise.fr/Article/Entity...eur-aux-DBA--/

    C'est très intéressant.

    A+
    "Winter is coming" (ma nouvelle page d'accueil)

  15. #55
    Invité
    Invité(e)
    Par défaut
    Merci pour le lien.

    Après lecture, Entity Framework même s'il génère des requêtes T-SQL parfois très compliquées à lire, est tout de même plus performant dans toutes les exemples cités dans l'article. Je crois que la prochaine fois qu'un DBA me sorte des trucs du genre "éviter les ORM !" je lui balance direct le lien

  16. #56
    Membre expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Novembre 2004
    Messages
    1 795
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2004
    Messages : 1 795
    Points : 3 173
    Points
    3 173
    Par défaut
    Après lecture, Entity Framework même s'il génère des requêtes T-SQL parfois très compliquées à lire, est tout de même plus performant dans toutes les exemples cités dans l'article. Je crois que la prochaine fois qu'un DBA me sorte des trucs du genre "éviter les ORM !" je lui balance direct le lien
    Pour ma part ce n'est pas les requêtes portant sur des SELECT qui me font peur... c'est les travers (quand non maîtrisé) du lazy loading mais surtout la non utilisation des SP pour les opérations INSERT/UPDATE/DELETE.
    Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
    MCTS Database Development
    MCTS Database Administration

  17. #57
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par iberserk Voir le message
    Pour ma part ce n'est pas les requêtes portant sur des SELECT qui me font peur...
    Oh que si ! Les requêtes portant sur les SELECT sont bien à prendre en compte. Ce sont elles qui rappatrient les données dont on a besoin. Et si le développeur n'a pas pris le soin de bien de définir sa requête Linq To Entities pour ne récupérer que les données dont il a besoin cela peut jouer dans les performances. Par exemple récupérer tous les Contacts se trouvant en base pour ensuite faire un foreach là-dessus et récupérer ceux qui sont des clients est vachement plus coûteuse en mémoire et aussi en performance par rapport à une requête qui met une clause where dans la requête Linq To Entities avant exécution par EF.

    Citation Envoyé par iberserk Voir le message
    c'est les travers (quand non maîtrisé) du lazy loading
    Je ne vois pas trop où se trouve le problème. Le lazy loading permet le chargement à la demande et par défaut il est à True dans EF4. Si elle détériorait les performances je ne pense pas que Microsoft l'ait mis à True alors qu'il était à False dans les versions antérieures d'EF. De plus rien ne t'empêche de le remettre à False cela n'améliorera en rien les performances sauf qu'il te faudra mettra un peu de code pour charger les données de navigations c'est à dire charger manuellement ces données de navigation.

    Citation Envoyé par iberserk Voir le message
    mais surtout la non utilisation des SP pour les opérations INSERT/UPDATE/DELETE.
    Là encore je ne suis pas du tout d'accord avec toi. L'utilisation des SP pour les opérations INSERT/UPDATE/DELETE évite seulement la génération de la requête T-SQL par EF et le gain de temps ne dévient considérable que si tu as des centaines de milliers de lignes à insérer, supprimer ou modifier.

  18. #58
    Membre chevronné
    Profil pro
    Inscrit en
    Mars 2005
    Messages
    1 273
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2005
    Messages : 1 273
    Points : 2 202
    Points
    2 202
    Par défaut
    Ce qui tues les performances, ce ne sont pas les générateurs de SQL; la plupart du temps; ce sont les scalaires et les relations faites en dépit du bon sens.

    Même si on utilise un ORM; rien n'empêche de faire preuve de bon sens et d'intelligence.

    Tout n'a pas à être dans la base et tout n'a pas à utiliser un ORM.

    C'est un principe idiot que dire mon application accède à la donnée d'une seule et unique façon !

    Le travers non maitrisé du lazy loading (qui ne devrait pas exister selon moi) c'est la génération de code. En gros, le lazy loading, c'est surtout du lazy coding. Et après ça fini en psychanalyse généralisée sur les bienfaits et les méfaits des ORM....

    Le CRUD n'a pas besoin de procs stocks. De même qu'un insertion massive / bulk n'a jamais nécessité de change tracking.

  19. #59
    Membre expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Novembre 2004
    Messages
    1 795
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2004
    Messages : 1 795
    Points : 3 173
    Points
    3 173
    Par défaut
    Je ne vois pas trop où se trouve le problème. Le lazy loading permet le chargement à la demande et par défaut il est à True dans EF4. Si elle détériorait les performances je ne pense pas que Microsoft l'ait mis à True alors qu'il était à False dans les versions antérieures d'EF. De plus rien ne t'empêche de le remettre à False cela n'améliorera en rien les performances sauf qu'il te faudra mettra un peu de code pour charger les données de navigations c'est à dire charger manuellement ces données de navigation.
    Attention, je n'ai rien contre les ORM... Immobilis le sait bien... je dis juste qu'ils apportent tellement en terme de développement (et loin de moi l'idée de revenir la dessus) qu'il est aisé de ne pas être vigilant... sur les travers du lazyloading dans une boucle foreach sur l'entité qui génère 500 requêtes si 500 éléments à parcourir... bonjour les perfs...

    D'ailleurs les préco de MS pour le chargement de tels objets est tout autre (voir la vidéo présente en lien dans ce topic).


    Là encore je ne suis pas du tout d'accord avec toi. L'utilisation des SP pour les opérations INSERT/UPDATE/DELETE évite seulement la génération de la requête T-SQL par EF et le gain de temps ne dévient considérable que si tu as des centaines de milliers de lignes à insérer, supprimer ou modifier.
    Le CRUD n'a pas besoin de procs stocks.
    La par contre je suis plus affirmatif: (et mon petit stagiaire amoureux d'ENTITIES dont l'action DELETE prenait 15 secondes à vite compris d'ailleurs...)
    Essayez de supprimer un utilisateur ainsi que ses 1000 commandes en ENTITIES et faites le en SP ensuite...
    Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
    MCTS Database Development
    MCTS Database Administration

  20. #60
    Membre expérimenté Avatar de davcha
    Profil pro
    Inscrit en
    Avril 2004
    Messages
    1 258
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations forums :
    Inscription : Avril 2004
    Messages : 1 258
    Points : 1 539
    Points
    1 539
    Par défaut
    Citation Envoyé par iberserk Voir le message
    Essayez de supprimer un utilisateur ainsi que ses 1000 commandes en ENTITIES et faites le en SP ensuite...
    Tu supprimes juste l'utilisateur, non ?... Enfin, ça dépend si tu as un cascade delete...

    Enfin, je dis ça, mais j'utilise pas EF4, moi.

Discussions similaires

  1. Réponses: 0
    Dernier message: 21/05/2015, 21h15
  2. Mesure des performances d'Apache
    Par yanis97 dans le forum Apache
    Réponses: 2
    Dernier message: 22/12/2009, 17h21
  3. Mauvaise performance avec Linq to sql
    Par Wasrack dans le forum Linq
    Réponses: 2
    Dernier message: 30/09/2009, 09h45
  4. Mesure des performances
    Par DjDavOnline dans le forum OpenCV
    Réponses: 2
    Dernier message: 13/01/2009, 09h20

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