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

[Immobilis]

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

A+

[h2s84]

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).

[Immobilis]

Salut

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+

[h2s84]

Envoyé par Immobilis

Tu me diras si cet objectif est atteint

Compte sur moi.

[nah666]

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.

[Er3van]

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 c# :

db.Customers.AddObject(c);

et

Code c# :

db.AddToCustomers(c);

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

[Immobilis]

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.

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.

Envoyé par Er3van

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

Code c# :

db.Customers.AddObject(c);

et

Code c# :

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:

Avec procédure stockée:

[Er3van]

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...

[Immobilis]

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

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

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

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.

[Er3van]

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 !

[Immobilis]

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.

[davcha]

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.

[Er3van]

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 ?

[Immobilis]

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.

[Immobilis]

Envoyé par davcha

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

Le quoi?

[iberserk]

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'

[Immobilis]

Envoyé par iberserk

->Immobilis: que te retournes celà:

Code :

Ceci

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

[iberserk]

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

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

[Immobilis]

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

[iberserk]

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/