Discussion :

[falcon74]

J'ai fait mes tests de performance, voici les résultats du mode DirectPath et les résultats du mode bulk.

Mon programme lit un fichier depuis un ou plusieurs threads en //.
Chacun reformate chaque ligne, puis la passe à un injecteur qui toutes les 10 000 lignes lance l'injection du groupe dans Oracle.

Le test a été fait sur un fichier de 2 millions de lignes.

La machine est un portable Dell avec un cpu pas trop mauvais, mais un HDD a chier, donc des résultats de test de perf pas forcément logique lors de l'augmentation du nombre de lecteurs.

Nb Lecteurs | Mode | Durée de traitement
1 | DP | 116 s
2 | DP | 150 s
4 | DP | 144 s
1 | Bulk | 60 s
2 | Bulk | 64 s
4 | Bulk | 56 s

Le mode directPath est plus lent que le mode bulk sur ma machine, cela m'étonne et je pense qu'il faut que je fasse des réglages car les 2 devraient être plus proche que cela, même si dans l'absolu je suis quand même à environs 15 000 lignes par seconde en mode DirectPath.

En gros des perfs pas dégeu, mais l'écart avec le mode bulk m'étonne.

Sinon d'un point de vu utilisation des fonctions DirectPath de la lib :

- L'obligation de faire la conversion de tous les types en char* avant l'appel de la fonction OCI_DirPathSetEntry, me donne une sensation de lourdeur dans son usage par rapport aux mode bulk qui prend directement les tableaux dans le type du champs. Enfin ca reste une sensation, le nombre de ligne suplémentaire est limité.

- Le fait que la fonction OCI_DirPathSetEntry necessite un void* et pas un const char* pour la valeur est imposé par OCI, ou bien il est possible de passer autre chose qu'un char* ?

- Pareil pour le paramètre name de OCI_DirPathSetColumn qui est de type char* et pas const char* ?

- Les index et les numéros de colonne qui commence à 1 au lieux de 0, c'est pas top top, c'est un fonctionnement un peu contre nature en c/c++

Voila pour mes première remarques.

Je pourrais t'en faire d'autre la semaine prochaine après un peu plus d'utilisation de la lib.

[Vincent Rogier]

il faut savoir que l'api direct path a été crée pour charger des flux textes externes (des fichiers quoi !). Donc, cela n'est pas vraiment adpaté si les données sont internes au programme et déja sous forme de données non texte...

Les index commence à 1 pour respecter la logique des OCI_GetXXX() des resultset afin que tout index démarre à partir de la même valeur dans toute la lib

Pour OCI_DirPathSetColumn(), l'absence du const est un oubli qui sera corrigé en 3.3 (mais c'est un détail)

Pour le OCI_DirPathSetEntry(), c'est un void * et non par un char * afin de pouvoir passer des contenus binaires (BLOB, RAW,...) depuis des lectures binaires depuis des fichiers non textes

Pour les perfs, je pense que les conversions de données que tu fais sont responsables de la lenteur. Il serait intéressant de mesure les temps de ces conversions afin de le retrancher au temps total

[falcon74]

OK, donc mon fichier a lire reformater plus injecté n'est pas forcement la meilleur utilisation du mode DirectPath.

Pour les index, je m'en doutais mais je n'ai résisté à l'envie de faire la remarque

L'absence du const pose un problème quand on lit le prototype de la fonction, je me suis demandé pourquoi elle pouvait modifier les données pointées. C'est un détail, mais je suis tatillons sur celui la apres de mauvaises exépriences.

Pour m'assurer de qui me ralentit, je ferais un test d'injection pure en DirectPath sans conversion de mes valeurs en passant des constantes à leur place. Comme ca, plus de doute !

[Vincent Rogier]

Salut,

j'ai fait un petit prog de bench direct path/bulk array...

Le code du prog est en pièce jointe...

Concrètement on bosse sur la table suivante :

Code :

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

create table test_directpath(val_int number, val_str varchar2(30));

Le programme initialise des tableaux de 2000 éléments (chaines de caractères pour les deux colonnes).

Pour chaque méthode, on fait 1000 insertions de ces tableaux, ce qui revient à insérer 2 fois 2 millions de lignes et donc au total 4 millions..

Le résultat est le suivant :

*******TEST 1 (MODE DIRECT PATH) *******************
2000000 row(s) loaded

*******TEST 2 (MODE BULK ARRAY) *******************
2000000 row(s) loaded

****************** RESULTS ***********************
TOTAL TIME DIRECT PATH : 06785 (set =00273, load=06509, commit=00003)
TOTAL TIME BULK ARRAY : 24136 (exec=24060, commit=00076)

******************** END ************************

Le mode direct path est beaucoup plus rapide (selon mon jeu de tests 4 à 20 fois plus rapide...). En fait plus le nombre de lignes est grand, plus l'écart se creuse...

Petite précision qui explique aussi les résultats de tes tests différents des miens. Le mode direct path est toujours plus rapide en terme de set+load que le temps d'une exécution en mode bulk.
Par contre la première itération d'insertion donne l'avantage au mode bulk... Mais le temps mis par le mode bulk est le même pour chaque itération (sans compter que le temps du commit et exponentiellement lié au nombre de lignes total) alors que le temps par itération du mode direct path diminue et que son temps de commit est constant, quelque que soit le nombre d'enregistrement.

Donc, le mode direct path est d'autant plus intéressant qu'il y a d'itération d'insertion, donc plus intéressant sur des gros volumes.

[falcon74]

Hello,

J'ai fait un test avec ton code, et j'ai le meme ratio en résultat entre bulk et direct path.

Par contre dans mon programme, apres quelques modif par rapport à ton exemple (j'arrete de faire un finish et free toutes les 1000 lignes .... ) j'arrive à une égalité entre direct path et bluk.

En fait, le gain du direct path est annulé par une opération supplémentaire que je suis obligé de faire avec mon modèle de donnée par rapport au mode bulk.

Donc quand j'aurai adapté mon modèle, voir même quand je l'aurai changé pour le rendre peu couteux à manipuler pour les 2 modes, le mode direct path sera plus rapide.

Merci de ton aide pour comprendre comment tout ca marche