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

Bonjour à tous,

J'ai rédigé ce petit papier pour bousculer, un peu, les certitudes au sujet des ORM et de leurs performances: http://immobilis.developpez.com/tuto...ity-framework/

N'hésitez pas à me dire ce que vous en pensez :ccool:

A+

Salut,

J'y ai jeté un coup d'oeil vite fait !
Le sujet abordé est intéressant et l'article très bien écrit.
J'ai mis l'article dans ma liste de tutos en attente.

A première vue, j'ai l'impression que tu t'es trop acharné sur l'architecture de ton application alors qu'il s'agit juste de tester et comparer les performance de requêtes (SQL, Ling To SQL et Linq To Entities).

Salut

Citation:

---

Envoyé par h2s84

A première vue, j'ai l'impression que tu t'es trop acharné sur l'architecture de ton application alors qu'il s'agit juste de tester et comparer les performance de requêtes (SQL, Ling To SQL et Linq To Entities).

---

Choix difficile en vérité. J'ai voulu éviter que le lecteur aille trop vite au résultats. En passant par le code des fournisseurs, j'espère qu'il prendra le temps de comprendre le code.

Tu me diras si cet objectif est atteint :)

A+

Citation:

---

Envoyé par Immobilis

Tu me diras si cet objectif est atteint :)

---

Compte sur moi. :ccool:

Excellent article, très intéressant, pour faire des choix et connaitre les différences.

L'introduction, quoi qu'un peu longue, sur ton archi, amène bien le découpage et les besoins.

A noter également, avec une bonne abstraction on peut passer de l'un à l'autre sans (trop) de mal.

Comme je te l'ai déjà dit dans un autre poste, très bon article.

Par contre à la deuxième lecture quelque chose me surprend :
L'utilisation de Linq to Entities avec des SP est plus performantes que Linq to Entities et très proche des performances de SQL(Command)...

Cela me surprend d'autant que j'ai eu les résultats très différent en faisant un benchmark sur mon application au boulot.

Pour info j'avais un programme qui en gros, supprimait 100 lignes, en rajoutait 100, et faisais ça sur environ 1 million de lignes en tout.
Les résultats que j'ai obtenu, c'est que LinqToEntitesSP donne quasiment les même performances que LinqToEntites, alors que SQL(Command) était 9 fois plus rapide.

Du coup je me pose la question de savoir s'il y a une différence de performance entre :

Code:

---

db.Customers.AddObject(c);

---

et

Code:

---

db.AddToCustomers(c);

---

Et si par hasard on n'a pas, toi comme moi, des mauvaises optimisations au niveau du code...

Citation:

---

Envoyé par Er3van

L'utilisation de Linq to Entities avec des SP est plus performantes que Linq to Entities et très proche des performances de SQL(Command)...

---

Cette discussion promet d'être enrichissante :)
Je regarde surtout le tableau récapitulatif. Sur mon portable Linq+Cmd effectue deux cycles complets le plus rapidement. C'est très serré avec EntitiesSqlSP. Ensuite il faut regarder le détail des opérations.

Citation:

---

Envoyé par Er3van

Pour info j'avais un programme qui en gros, supprimait 100 lignes, en rajoutait 100, et faisais ça sur environ 1 million de lignes en tout.
Les résultats que j'ai obtenu, c'est que LinqToEntitesSP donne quasiment les même performances que LinqToEntites, alors que SQL(Command) était 9 fois plus rapide.

---

Quand on regarde les requêtes générée par le fournisseur EntitiesCustomerProvider:

Code:

---

exec sp_executesql N'insert [dbo].[Customers]([Id], [LastName], [FirstName]) values (@0, @1, @2) ',N'@0 uniqueidentifier,@1 varchar(50),@2 varchar(50)',@0='63716843-0523-43DB-814D-720F0EA89D55', @1='7pL7ob8pmrWDC0k',@2='7pL7ob8pmrWDC0krI0a5'

---

et EntitiesSqlSPCustomerProvider:

Code:

---

exec [dbo].[CreateCustomer] @Id='E70A41CC-CC1C-4328-B24C-DA02038B6929', @LastName='lpPdOXNPPov8Qg5',@FirstName='lpPdOXNPPov8Qg5MLDVy'

---

J'ai du mal à imaginer que EntitiesCustomerProvider est plus rapide. D'ailleurs, il arrive bon avant dernier dans le tableau.

Citation:

---

Envoyé par Er3van

Du coup je me pose la question de savoir s'il y a une différence de performance entre :

Code:

---

db.Customers.AddObject(c);

---

et

Code:

---

db.AddToCustomers(c);

---

---

Si db.AddToCustomers(c) est bien l'appel à une procédure stockée, pour moi c'est clair. L'utilisation de procédures stockées rend le code plus rapide. Il suffit de regarder les deux graphiques pour s'en convaincre. Les échelles de temps sont les mêmes, 3mn
Sans procédure stockée:

http://immobilis.developpez.com/tuto...rfEntities.gif

Avec procédure stockée:

http://immobilis.developpez.com/tuto...itiesSqlSP.gif

Non justement ce n'est pas une procédure stockée, c'est une méthode générée par EF.

Les procédures stockées ne sont pas "plus rapides" avec SQL Server 2008 R2 à ma connaissance, sauf si tu as poussé le vice jusqu'à optimiser le plan d'éxecution, et encore... Et c'est pour ça que ça me surprend.

Le bon dernier c'est Linq et ça ne m'étonne pas, ce qui me surprend, c'est que Linq to Entites avec SP soit bien plus performant que Linq to Entities tout court, et qu'il ait des performances proche de SQL Command.
Après ça peut venir du jeu de test...

Citation:

---

sauf si tu as poussé le vice jusqu'à optimiser le plan d'éxecution

---

Je suis pas très bon en ça... :P

En premier les méthodes natives, en deuxième les méthodes avec les proc stock.

http://immobilis.developpez.com//tut...itiesVsSQL.png

Je doutes que la différence change quelque soit l'environnement.
Création, Entity seul:

Code:

---

exec sp_executesql N'insert [dbo].[Customers]([Id], [LastName], [FirstName]) values (@0, @1, @2)',N'@0 uniqueidentifier,@1 varchar(50),@2 varchar(50)',@0='DAF9D021-F60E-47EE-881C-851DFF8F8EEA',@1='dMtAktsNSeobzEY',@2='dMtAktsNSeobzEYsK58x'

---

Contre Entity + PS

Code:

---

exec [dbo].[CreateCustomer] @Id='12503D00-B5C2-40CD-B0A2-FCBC96ECC72A',@LastName='q0SuytswT6DYuOM',@FirstName='q0SuytswT6DYuOM3s2NJ'

---

Suppression, Entity seul:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

exec sp_executesql N'SELECT TOP (2) [Extent1].[Id] AS [Id], [Extent1].[LastName] AS [LastName], [Extent1].[FirstName] AS [FirstName] FROM [dbo].[Customers] AS [Extent1] WHERE [Extent1].[Id] = @p__linq__0',N'@p__linq__0 uniqueidentifier',@p__linq__0='77863927-C8C4-4090-A80F-2D8C2BF94810' go exec sp_reset_connection go exec sp_executesql N'delete [dbo].[Customers] where ([Id] = @0)',N'@0 uniqueidentifier',@0='77863927-C8C4-4090-A80F-2D8C2BF94810' go exec sp_reset_connection go

---

Contre Entity + SP

Code:

---

1 2 3 4

exec [dbo].[DeleteCustomer] @ID='79AE9A99-ED2C-4567-85F4-06DD7FCED110' go exec sp_reset_connection go

---

Y'a pas photo.

Je vais essayer de prendre le temps ce week end de faire le test, entre EF avec SP, EF sans SP et SQL Command brut, parce que les différences que tu montres me surprennes.

Je n'ai pas suivi tout ton code, mais quand tu fais des insert de masse, tu passes des collections à tes méthodes, ou tu passes individuellement chaque objet ? C'est peut-être ce qui fait la différence entre nos benchmark !

Citation:

---

Envoyé par Er3van

Je n'ai pas suivi tout ton code, mais quand tu fais des insert de masse, tu passes des collections à tes méthodes, ou tu passes individuellement chaque objet ? C'est peut-être ce qui fait la différence entre nos benchmark !

---

Je les insère un par un. Pour de vrais insertions en masse, il faudrait utiliser un bulkinsert.

Faudrait que SQLPro participe à cette discussion. Il pourrait y apporter une grosse valeur ajoutée, je pense.

Sinon, pour l'article, un conseil : évite le code centré. C'est assez illisible.

Citation:

---

Envoyé par Immobilis

Je les insère un par un. Pour de vrais insertions en masse, il faudrait utiliser un bulkinsert.

---

Ah ben voilà la diff alors, je passe par un bulkinsert... Là tu vois la différence, vraiment.
(ça tombe bien j'avais pas envie de coder avec le temps qu'il fait...)

C'est dommage qu'on ne puisse pas de la même façon optimiser les méthodes EF.
Parce que ce qui cause une perte de temps c'est la recherche de l'ID systématique, notamment pour l'insert et le delete.

Tu récupères les requêtes générées via SQL Profiler ?

Citation:

---

Envoyé par Er3van

C'est dommage qu'on ne puisse pas de la même façon optimiser les méthodes EF.
Parce que ce qui cause une perte de temps c'est la recherche de l'ID systématique, notamment pour l'insert et le delete.

Tu récupères les requêtes générées via SQL Profiler ?

---

Les méthodes de EF sont optimisées pour certains scénarios. Elles répondent à un cahier des charges. Il faut juste bien comprendre dans quelles situations les utiliser.
Oui j'utilise SQL Server Profiler.

Citation:

---

Envoyé par davcha

Sinon, pour l'article, un conseil : évite le code centré. C'est assez illisible.

---

Le quoi?

Citation:

---

exec [dbo].[CreateCustomer] @Id='E70A41CC-CC1C-4328-B24C-DA02038B6929', @LastName='lpPdOXNPPov8Qg5',@FirstName='lpPdOXNPPov8Qg5MLDVy'

---

Ceci est recolté via le SQL PROFILER... CreateCustomer est donc bien une SP présente sur le server SQL...

->Immobilis: que te retournes celà:

Code:

---

1 2 3 4

SELECT * FROM [taDataBase].sys.PROCEDURES WHERE NAME='CreateCustomer'

---

Citation:

---

Envoyé par iberserk

->Immobilis: que te retournes celà:

Code:

---

1 2 3 4

SELECT * FROM [taDataBase].sys.PROCEDURES WHERE NAME='CreateCustomer'

---

---

Ceci

Citation:

---

name.......................................CreateCustomer
object_id..................................37575172
principal_id................................NULL
schema_id................................1
parent_object_id........................0
type.........................................P
type_desc.................................SQL_STORED_PROCEDURE
create_date...............................2011-06-25 00:20:33.653
modify_date...............................2011-06-25 13:03:57.620
is_ms_shipped............................0
is_published...............................0
is_schema_published...................0
is_auto_executed.......................0
is_execution_replicated................0
is_repl_serializable_only................0
skips_repl_constraints..................0

---

C'est EF qui a crée lui même cette SP?

Si oui bon les règles de nommage! je rêve! :ccool:

Non non, c'est moi pourquoi? J'ai enfreint une règle de nommage?

Citation:

---

Non non, c'est moi pourquoi? J'ai enfreint une règle de nommage?

---

Beaucoups vont dire que c'est subjectif mais oui... tout en majuscule avec undescore, SP_ en prefixe des SP...

http://sqlpro.developpez.com/cours/standards/

Citation:

---

Envoyé par iberserk

Beaucoups vont dire que c'est subjectif mais oui... tout en majuscule avec undescore, SP_ en prefixe des SP...

http://sqlpro.developpez.com/cours/standards/

---

J'ai fait la même remarque il y a peu, voici ce que m'a répondu Tomlev :

Citation:

---

Envoyé par tomlev

Ouais mais l'article est pas tout neuf, et les conventions, ça peut évoluer...

C'est vrai que jusqu'ici, en pratique j'ai surtout vu des noms sous la forme décrite dans l'article, mais on voit de plus en plus de noms de tables en CamelCase, notamment dans les articles de Microsoft concernant Entity Framework et les technos qui tournent autour

De toutes façons une convention, ce n'est pas unique, tout le monde n'est pas obligé d'adopter la même

---

Du coup, j'en déduis que les deux sont utilisés...

Citation:

---

Envoyé par Er3van

Du coup, j'en déduis que les deux sont utilisés...

---

Oui, oui, d'autant qu'en C# CamelCase est la convention (les majuscules ont beaucoup d'importance). Comme le nom de la procédure stockée est repris par Entity Data Model il vaut mieux respecter CamelCase. Un underscore dans le code est "interdit" dans la nomenclature.

Et bien je ne suis pas daccord avec lui...

MICROSOFT, pour toucher les développeurs, tente d'instaurer le CAMEL CASE, et pourquoi?

Simple... c'est bien pratique quand on génère l'EDMX puisque celui-ci garde par défaut le nom des tables du coups "c'est pas bo ces classes en MAJUSCULE"... c'est tout...

De toute manière MICROSOFT n'a JAMAIS respecté les normes de nommage quand il s'agit d'intéragir avec .NET...

Bien avant LINQ, il fallait voir les SP et tables générées pour la gestion utilisateur/membership/profile/role intégrée ASP.NET!
Avec NVARCHAR et GUID au taquet en plus(sans débattre sur l'utilisation du GUID bien sûr :-))

+1 pour les GUID.

C'est pas tant l'utilisation de CamelCase dans les procédures stockées qui me gêne, c'est plus dans les index, keys, attributs de table, etc...

Citation:

---

Envoyé par iberserk

Et bien je ne suis pas daccord avec lui...

---

:mouarf::mouarf: Grand troll en perspective.

Bon, pour info, en l’occurrence on parle aussi de PascalCase. Je suis pas trop à cheval là dessus. Perso, en fait, je "PascalCase" (Microsoft) tandis que d'autres "camelCase":

• http://blogs.msdn.com/b/brada/archiv.../03/67024.aspx
• http://msdn.microsoft.com/en-us/libr...40(VS.80).aspx

A vous de voir si vous préférez

Code:

---

db.SP_CREATE_CUSTOMER(obj.Id, obj.LastName, obj.FirstName);

---

ou

Code:

---

db.CreateCustomer(obj.Id, obj.LastName, obj.FirstName);

---

dans votre code.

A+

Citation:

---

Grand troll en perspective.

---

????

OK... une des origines de cette convention est que :

1. Certaines bases de données son en collation CS ou BINAIRE... d'ou l'utilité d'utiliser les MAJUSCULES...
2. Celà limite l'écriture par des développeurs (ou DBA peu consciencieux...) de requètes avec des CASSES différentes, ce qui maximise l'utilisation du cache, en effet sachez que si vous faites
   Code:

   ---

   SELECT NOM FROM MATABLE

   ---

   et
   Code:

   ---

   SELECT NOM FROM matable

   ---

   et bien vous forcez SQL SERVER à générer deux plans d'executions et à les mettre deux fois en cache...

Citation:

---

A vous de voir si vous préférez

db.SP_CREATE_CUSTOMER(obj.Id, obj.LastName, obj.FirstName);
ou
db.CreateCustomer(obj.Id, obj.LastName, obj.FirstName);dans votre code.

A+

---

Encore une fois je ne vois pas en quoi le fait de renommer votre SP dans votre DBML est compliqué si c'est ca qui vous gène???

Citation:

---

Envoyé par iberserk

sachez que si vous faites

Code:

---

SELECT NOM FROM MATABLE

---

et

Code:

---

SELECT NOM FROM matable

---

et bien vous forcez SQL SERVER à générer deux plans d'executions et à les mettre deux fois en cache...

---

En mode troll:
D'ou l'utilité de prendre un ORM qui fera toujours la requête de la même facon!
J'ai bon? :pastaper: :aie:

Citation:

---

Envoyé par iberserk

????

---

C'est que parfois dans mon boulot cela a donné lieu à des disputes mémorables :mouarf:

Citation:

---

Envoyé par iberserk

Celà limite l'écriture par des développeurs (ou DBA peu consciencieux...) de requètes avec des CASSES différentes, ce qui maximise l'utilisation du cache, en effet sachez que si vous faites

---

Intéressant, je n'y avais jamais songé. Faut vraiment être DBA pour penser à tout ça!
Sinon, j'imagine que produire un tel document de convention est/était nécessaire parce qu'il n'y n'avait pas d'intellisens. Du coup, en mettant tout le monde en majuscules c'est plus pratique. Par contre, sachant que le renommage n'est pas aussi simple que sous Visual Studio, utilisez tout ces préfixes est un travail de dingue!

Citation:

---

Envoyé par iberserk

Encore une fois je ne vois pas en quoi le fait de renommer votre SP dans votre DBML est compliqué si c'est ca qui vous gène???

---

Je n'ai pas vu la possibilité d'ajouter des alias...

Citation:

---

Envoyé par Nathanael Marchand

En mode troll:
D'ou l'utilité de prendre un ORM qui fera toujours la requête de la même facon!
J'ai bon? :pastaper: :aie:

---

+1
Autre doc: http://msdn.microsoft.com/en-us/libr...72(VS.71).aspx

Citation:

---

Envoyé par Immobilis

Je n'ai pas vu la possibilité d'ajouter des alias..

---

Ah si ok :P :mouarf:

Bah alors, tout le monde est heureux! :ccool:

Très intéressant! http://msdn.microsoft.com/fr-fr/netf.../hh237550.aspx

Code:

---

db.SP_CREATE_CUSTOMER(obj.Id, obj.LastName, obj.FirstName);

---

Et pour info, Iberserk me corrigera si je me trompe, mais il me semble que le préfixe "SP" pour les procédures stockées devrait être réservé à la seule utilisation de Microsoft dans SQL Server. Les procédures stockées applicatives doivent être nommée différemment, par exemple

Code:

---

db.CODE_APPLI_CREATE_CUSTOMER(obj.Id, obj.LastName, obj.FirstName);

---

Nathanael :

Citation:

---

J'ai bon?

---

Oui tout à fait...

Citation:

---

Et pour info, Iberserk me corrigera si je me trompe, mais il me semble que le préfixe "SP" pour les procédures stockées devrait être réservé à la seule utilisation de Microsoft dans SQL Server. Les procédures stockées applicatives doivent être nommée différemment, par exemple

---

rien ne vous empeche de garder les conventions de nommage CHARP dans votre EDMX.... y compris pour les procédures stockées et fonctions tables (ne les oublions pas...).

Je vois que ça se discute pas mal.

Pour ma part je n'ai pas encore eu le temps ce week end pour me plonger dans le tuto.

Sinon pour ceux qui n'avaient pas assisté à l'après-midi du développement sur Entity Framework chez Microsoft je vous conseille de visionner le webcast ici.
ça parle de tout et même de l'optimisation des requêtes Linq To Entities dans la partie 9 du webcast et cette partie pourra intéresser plus d'un et c'est vraiement très instructif vu que la plupart du temps on se lance dans EF sans comprendre ce qui passe derrière.

Merci docteur:D

Je vais aller voir ca, je n'ai pas vu cette webcast.

Excellentes analyse 'pas besoin d'être un expert SQL pour savoir qu'ici il vaut mieu utiliser l'include: il génère 200000 requêtes sans'

Citation:

---

Envoyé par Immobilis

Très intéressant! http://msdn.microsoft.com/fr-fr/netf.../hh237550.aspx

---

Bouhouhouh personne lit mes post :cry: :cry:

Pardon:?

Bonjour à tous !

L'article est trés trés interressant mais j'ai 2 ou 3 petites questions.
Au debut de la sortie de EF, j'ai voulu l'utilisé mais j'ai toujours trouvé des différences de performances par rapport à l'utilisation des Dataset ou des objets ADO.Net (SqlCommand ...). Les temps de chargement pour des petites tables était trés important, bien sur je ne connaissais pas cette techno et je me rend compte aujourd'hui qu'il existe de nombreuses possibilités d'optimisation. L'une d'elle est l'utilisation de procédures stockées, mais quand on a une base d'environ 50 tables, c'est fait tout de meme pas moins de 200 PS qu'il faut créer !!!

Mes questions :

• Utilisez vous des PS (CRUD) pour chaque table ou bien attaquez vous directement les tables ?
• Quelles sont vos optimisations sous EF ?

Salut,

Merci pour ton accueil de cet article :)

Citation:

---

Envoyé par ddaime

c'est fait tout de meme pas moins de 200 PS qu'il faut créer !!!

---

Il existe des générateurs de PS pour les opérations du CRUD.

Citation:

---

Envoyé par ddaime

Utilisez vous des PS (CRUD) pour chaque table ou bien attaquez vous directement les tables ?

---

Dans la mesure du possible, au regard des résultats, dans tous les cas, il vaut mieux faire des PS dès que c'est possible. C'est effectivement du travail. Cela peut donner des procédures comme: GetUsersByName, GetUserById, GetUsersByTown, etc. Tu peux aussi imaginer faire un UsersSelectAll au démarrage de l'application, mettre les données en cache et faire la recherche par le code. Tu gardes ainsi le jeu de données sur le serveur web et tu ne requêtes plus la base.
Si on retourne la question: dans quels cas une procédure stockée répond moins bien au besoin? Je dirais toutes les fois où la liste des champs ainsi que les clauses de la requête sont construites par le code. Ces cas là sont assez rares. Cela arrive dans le cas de moteur de recherche je dirais.

Citation:

---

Envoyé par ddaime

Quelles sont vos optimisations sous EF ?

---

Finalement, j'utilise assez peu EF :P Les PS sont une bonne optimisation. Je te suggère de regarder le web cast deuxième lien dans les références: http://immobilis.developpez.com/tuto...amework/#LVIII. On peut en retenir une chose essentielle: ne demander à la base de données que ce dont on a réellement besoin.

A+