Discussion :

[Er3van]

Hello,

Je suis aujourd'hui confronté à un problème de performances, comme dit dans le titre, sur des requêtes d'insertion.
Ma crainte c'est que la réponse soit simplement le fait c'est la limite d'Entity Framework, que les Insert sont lents de façon inhérente à la techno (plus fait pour des "select/update" unitaire j'en conviens.

Pour préciser un peu plus le soucis, il s'agit d'insertions "massives".
Le programme en question extrait d'un fichier XML des lignes à insérer en base, environ 500 000 dans le fichier. Le traitement prend actuellement plusieurs heures (environ 4h), ce qui n'est pas compatible avec les contraintes métiers qui sont derrières.

Entity Framework avait été choisi à l'époque pour simplifier la vie de la maintenance (car Entity est utilisé pour d'autres applications) et parce que le problème de performance ne se posait pas à l'époque car le volume de données a été mal estimé par le client (~10x plus important que prévu)

Bref, j'ai essayé d'optimiser la structure de la base, supprimer des index pour gagner du temps, rien n'y fait ! (A noter qu'une contrainte réseau accentue le phénomène... comme si ça ne suffisait pas !)

Toujours est-il que ma question est là suivante :
Peut-on faire quelque chose pour améliorer ça avec Entity Framework ? Faut-il se rabattre sur une solution "à la mano" type requête SQL "en dur" (car NHibernate semble trop coûteux à mettre en place du fait de l'état d'avancement) ?
J'ajoute que les solutions type Bulk ou SSIS ont été exclues pour des raisons d'infra (pas d'"applicatif" sur le server SQL...).

Si cela peut aider voici un bon de code qui fait l'insertion en Linq to SQL :

Code c# :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
 
using (CoverEntities context = new CoverEntities())
            {
                try
                {
                    T_G61_ITEMS Item = null;
 
                    // Get the XXX by ID
                    var xxx = context.XXX.First(x => x.ID == XID);
 
                    // Check if there is already an item for the given XXX, language and item
                    // It should only happen for some items described in multiple rows
                    var ExistingItems = from i in context.ITEMS
                                        where i.ITEMS_NM_ITEM.Equals(ItemID, StringComparison.CurrentCultureIgnoreCase)
                                        && i.ITEMS_ID_LANGUAGE_ID.Equals(LanguageID, StringComparison.CurrentCultureIgnoreCase)
                                        && i.XXX.ID == XXX
                                        select i;
 
                    // If there is no existing item
                    if (ExistingItems.ToList().Count == 0)
                    {
                        // Then create one
                        Item = new ITEMS
                        {
                            ITEMS_ID_LANGUAGE_ID = LanguageID,
                            ITEMS_NM_ITEM = ItemID,
                            ITEMS_NM_VALUE = ItemValue
                        };
 
                        // Add the reference to the XXX
                        xxx.ITEMS.Add(Item);
                    }
                    else
                    {
                        // Update the existing item
                        Item = ExistingItems.First();
                        Item.ITEMS_NM_VALUE = Item.ITEMS_NM_VALUE.TrimEnd() + ' ' + ItemValue.TrimStart();
                    }
 
                    // Save the context for change commit
                    context.SaveChanges();           
                }
                catch (Exception e)
                {
                    throw new DatabaseException(e.Message, e.InnerException);
                }
            }

PS : J'ai remplacé certains termes mais j'espère ne pas avoir cassé la sémantique...


Merci d'avance !

[Arnard]

Pareil, j'ai eu un projet de migration de données, EF ok pour quelques milliers de lignes, mais ensuite ça ne tenait plus la route. Une procédure stockée appelée par un agent obéissant à un calendrier a fait face sans souci !

Sinon, une réplication à sens unique ne pourrait pas résoudre le problème ? Genre Fusion ?

[Er3van]

La réplication supposerait que je sois maître des données entrantes, malheureusement ces données provienne d'une entreprise externe... (à moins que j'ai mal compris ce que tu entends par réplication).

En ce moment je regarde la solution "requêtes en dur", on verra si les performances tiennent la route !

[Arnard]

En réplication sur SQL Server on distingue le push (le serveur envoie les données via notification) et le pull (l'abonné interroge le serveur pour identifier les données à rapatrier). Dans les deux cas cela implique la mise en place d'un serveur de publication sur le serveur source, ce qui n'est pas évident dans ton cas apparemment.

[Er3van]

Non, pas évident du tout ! Merci pour l'idée en tout cas !

Là je viens de passer en requête "en dur", y a pas photo.... j'suis sur un truc qui est de l'ordre de 50 000 insertions par minutes en local, contre 7 000 auparavant !

En regardant un peu dans le détail, j'ai l'impression que c'est l'auto-incrémente qui fait merder Entity Framework, il fait systématiquement (au milieu de l'insert) :

Code SQL :

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

1
2
3
4
 
select [ITEMS_ID_ITEM_ID]
from [dbo].[T_G61_ITEMS]
where @@ROWCOUNT > 0 and [ITEMS_ID_ITEM_ID] = scope_identity()

Alors que c'est inutile et consommateur...

J'essaye de voir si y a moyen de le paramétrer mais je vois pas trop à quel niveau...

[Nathanael Marchand]

Pour avoir eu le même cas que toi, (batch journalier de millions de lignes qui durait 48h) je suis passé par le bulk insert et la commande merge (c'était une fusion/insertion): 4min de batch
J'ai pas compris ton argument de "pas d'applicatif sur le serveur sql"

[Er3van]

Pour avoir eu le même cas que toi, (batch journalier de millions de lignes qui durait 48h) je suis passé par le bulk insert et la commande merge (c'était une fusion/insertion): 4min de batch

Comment c'est possible de réduire autant ??? O.o
Tu paramètres le merge à quel niveau du coup ?

J'ai pas compris ton argument de "pas d'applicatif sur le serveur sql"

Moi non plus je l'ai pas compris... (ce n'est pas "mon" argument... celui de l'admin SQL Server, pas basé en France dont intouchable...).

[Bluedeep]

J'ajoute que les solutions type Bulk ou SSIS ont été exclues pour des raisons d'infra (pas d'"applicatif" sur le server SQL...).

Je ne comprends pas cette phrase.
Pourquoi avoir exclu SSIS qui semble la seule solution logique ici ?

[Nathanael Marchand]

Le but de mon batch etait d'integrer un fichier de mise à jour client. Or cette mise à jour n'était pas incrémentale: on recevait tous les jours toute la base client! Dans le premier jet, ligne par ligne en C# je parsais le fichier puis allais vérifier en base si je devais faire un insert ou un update. C'est bien ok pour 1000 lignes mais des lors qu'on a 8millions...
Alors la solution a été de parser le fichier recu pour en faire un fichier CSV. Ce CSV est mis sur un repertoire réseau. Bulk Insert du fichier dans une table temporaire et enfin merge entre la table temporaire et la table réelle.

[Er3van]

Je ne comprends pas cette phrase.
Pourquoi avoir exclu SSIS qui semble la seule solution logique ici ?

Car SSIS n'est pas appointé (dans mon entreprise) comme solution valide, excepté pour de la BI, sur des serveurs mutualisés... C'est aussi idiot que ça.
En gros c'est l'admin qui n'est pas d'accord. Pas négociable.... (mais je suis le premier à avoir gueulé si ça peut te rassurer...)

[Er3van]

Finalement, après avoir comparé les performances des cas suivants :

- Utilisation EF standard pour insertion
- Utilisation EF avec proc stock pour insertion
- Utilisation "directe" proc stock pour insertion
- Insertion "directe"

Les meilleures performances sont incontestablement pour la dernière solution.
Certes, c'est pas propre, mais compte tenu du volume en question : tant pis !

J'ai juste rajouter une p'tite classe qui gère la connexion avec un singleton pour éviter les ouvertures/fermetures intempestive de la connexion, ça gagne encore un peu de temps.

L'option BulkCopy avait aussi été envisagée, mais beaucoup plus d'impact au niveau du code, et gestion compliquée d'une collection (gigantesque) d'objets.

Merci pour votre aide !

[Bluedeep]

Certes, c'est pas propre,

C'est en tout cas bien plus propre que d'utiliser EF dans ce cas !

Ici, tu travaille a priori sur de la donnée "brut", il n'y donc que des inconvénients (et aucune logique) à utiliser une couche d'encapsulation orientée "objets métier".

[Er3van]

C'est en tout cas bien plus propre que d'utiliser EF dans ce cas !

Oui et non, on perd en cohérence d'ensemble (logique "logicielle") et en maintenabilité, mais effectivement on gagne en efficacité et en logique "informatico-technique".

Cela dépend du contexte de travail tu me diras, dans une SSII ou une boite spécialisée en informatique type Editeur Logiciel, la logique métier serait la même que la logique informatique, donc aucun soucis, mais ce n'est pas mon cas.