Conseil d'optimisation

Version imprimable

19/01/2007, 10h37
Franck2mars

Conseil d'optimisation

Salut a tous,

je suis en train de faire un programme qui fait des insertions en base. je me pose une question quant à l'optimisation,

est-ce mieux d'ouvrir la connexion avant d'exécuter une procédure stockée et de la refermer apres chaque exécution.
Ou est ce mieux d'ouvrir la connexion avant de lancer toutes les procédures stockées et de refermer une fois que toutes les insertions en base ont été effectuées. J'ai des performances assez pourries, je comprends pas.
Je mets une moyenne de 10' pour insérer 1000 lignes à 39 champs.....
Qu'en pensez vous?
19/01/2007, 10h56
Ditch

Citation:

Envoyé par Franck2mars

Salut a tous,

je suis en train de faire un programme qui fait des insertions en base. je me pose une question quant à l'optimisation,

est-ce mieux d'ouvrir la connexion avant d'exécuter une procédure stockée et de la refermer apres chaque exécution.
Ou est ce mieux d'ouvrir la connexion avant de lancer toutes les procédures stockées et de refermer une fois que toutes les insertions en base ont été effectuées. J'ai des performances assez pourries, je comprends pas.
Je mets une moyenne de 10' pour insérer 1000 lignes à 39 champs.....
Qu'en pensez vous?

Tu peux ne l'ouvrir qu'une fois et a fermer à la fin. Utilises un try/catch/finally pour éviter de laisser la connexion ouverte si une exception est lancée.

C'est exactement ce que je fais :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Public Function Execute_ProcStock(ByRef connexion As ADODB.Connection, ByRef rs_insertion As ADODB.RecordsetClass, ByVal i As Integer) As Integer
        ' Exécution d'une Procédure Stockée de type Insertion ou Update 
        Dim MonResultat As Integer = -1
        Dim rang As Integer
        Dim MaCommande As String
        Try
            MaCommande = "ps_I_AddMERGE_DATA "
            If i = 0 Then
                rang = 1
            Else
                rang = 2
            End If
            MaCommande &= EntreCote(LTrim(Mid(tablo(i), rang, taille_PURCH_ORG))) & ","
            rang += taille_PURCH_ORG
            .....
 
            rs_insertion.Open(MaCommande, connexion)
        Catch ex As Exception
            If Not (connexion Is Nothing) Then connexion.Close()
            MonResultat = -1
        Finally
            If Not (connexion Is Nothing) Then connexion.Close()
        End Try

est ce bien d envoyer la connection et le recordset par adresse?

19/01/2007, 11h05
SuperB

il me semble que de toute façon si tu fermes ta connexion et que tu la réouvre par la suite ça ne dégage pas des pertes excessives de performances vu que la connexion est gardée dans une sorte de pool, donc elle est gardée en mémoire et très rapidement réouverte.

Concernant tes problèmes de performances ça me semble pas choquant vu la quantité de données à insérer. Si c'est vraiment un problème, tu peux changer de méthode d'insertion en utilisant par exemple la méthode par bulk insert, ou un truc du style.
19/01/2007, 11h07
Franck2mars

Tu as un exemple de bulk insert?
19/01/2007, 11h09
Bluedeep

Bonjour

Citation:

Envoyé par Franck2mars

Salut a tous,

je suis en train de faire un programme qui fait des insertions en base. je me pose une question quant à l'optimisation,

est-ce mieux d'ouvrir la connexion avant d'exécuter une procédure stockée et de la refermer apres chaque exécution.
Ou est ce mieux d'ouvrir la connexion avant de lancer toutes les procédures stockées et de refermer une fois que toutes les insertions en base ont été effectuées. J'ai des performances assez pourries, je comprends pas.
Je mets une moyenne de 10' pour insérer 1000 lignes à 39 champs.....
Qu'en pensez vous?

Que c'est très très lent !

Quel est le SGBD utilisé ?

Sinon, une solution (suivant le SGBD) est de faire ce genre d'insert massif au sein d'une seule transaction. Tel que c'est codè, là, il y a visiblement utilisation de la transaction implicite de la procstoc, donc une transaction pour chaque insert, ce qui n'est pas optimal du tout.

Pour ce qui est de la connection, le mieux est de n'en utiliser qu'une pour ce genre d'action.

F.
19/01/2007, 11h11
Franck2mars

donc, le mieux c de faire une seule transaction pour l exec de toutes mes proc stockees?
19/01/2007, 11h13
Bluedeep

Citation:

Envoyé par SuperB

Concernant tes problèmes de performances ça me semble pas choquant vu la quantité de données à insérer.

Désolé, mais je ne suis pas d'accord (du tout).

Si on multiplie par 1000, cele ferait quasi 3 heures pour insérer 1 000 000 de lignes, ce qui serait complétement délirant.
19/01/2007, 11h14
Franck2mars

c ce que je pense, c affreux.... surtout que je dois le faire par la suite sur 2 millions de lignes
19/01/2007, 11h15
Bluedeep

Citation:

Envoyé par Franck2mars

donc, le mieux c de faire une seule transaction pour l exec de toutes mes proc stockees?

Je n'ai pas dit cela en général mais dans le cas ici, oui, clairement :

- Entrer en transaction
- Boucle d'insertion
- Commit

et Rollback si exception : ainsi tu t'assure que l'insertion est soit complète soit non effectuée.
19/01/2007, 11h16
Bluedeep

Citation:

Envoyé par Franck2mars

c ce que je pense, c affreux.... surtout que je dois le faire par la suite sur 2 millions de lignes

J'ai précisément là une appli qui travaille avec des 1 à 5 millions de lignes en INSERT et je ne suis pas du tout dans ces temps (c'est en minutes : de 3 à 15, suivant le SGBD et la quantité).

Sinon, je réitére ma question supra : type de SGBD ?
19/01/2007, 11h18
SuperB

Citation:

Envoyé par Bluedeep

Désolé, mais je ne suis pas d'accord (du tout).

Si on multiplie par 1000, cele ferait quasi 3 heures pour insérer 1 000 000 de lignes, ce qui serait complétement délirant.

je parlais par rapport à la méthode utilisée... pour moi du ligne à ligne c'est lent par nature.
19/01/2007, 11h18
Franck2mars

pardon, c sql server 2K
19/01/2007, 11h21
Bluedeep

Citation:

Envoyé par SuperB

je parlais par rapport à la méthode utilisée... pour moi du ligne à ligne c'est lent par nature.

Non, si c'est dans une transaction, ca ne change presque rien dans la pratique.
Ici c'est lent vraissemblablement du fait du choix de la transaction implicite, choix que je trouve douteux dans le cas qui nous occupe.
19/01/2007, 11h21
Bluedeep

Citation:

Envoyé par Franck2mars

pardon, c sql server 2K

Oki.

Donc essaye en transac, tu vas voir, ca va tout de suite être mieux, j'en suis presque sur :D
19/01/2007, 11h26
Franck2mars

Et comment ca se met en oeuvre? j ai jamais fait de transac en vbnet
19/01/2007, 11h30
Bluedeep

Citation:

Envoyé par Franck2mars

Et comment ca se met en oeuvre? j ai jamais fait de transac en vbnet

Ben de la même maniére qu'en C# ou qu'avec n'importe quel langage en .Net.

- appeler méthode BeginTransaction sur l'instance de connection
- positionner l'instance de l'objet Transaction récupérée sur le retour de BeginTransaction dans la propriétés ad-hoc de l'instance de l'objet Command
- à la fin appeler la méthode Commit sur l'instance de l'objet Transaction.

Vous pouvez peut être quand même chercher un peu tout seul pour des choses aussi triviales.
19/01/2007, 11h38
Franck2mars

ok merci
19/01/2007, 11h40
Bluedeep

Citation:

Envoyé par Franck2mars

ok merci

De rien.

Et ce serait intéressant de poster le résultat des courses, aprés vos essais.