Discussion :

[promopub]

Bonjour

voici mon problème, j'execute une fonction PL/SQl qui me retourne un ResultSet d'une 30e de résultats. La requête de la procédure est assez complexe mais elle s'execute en moins de 30 ms à s'executer.
Etonnement c'est le premier resultset.next() qui prend énormément de temps (environ 9s)

voici mon code :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
long debut = System.currentTimeMillis();
System.out.println("debut : "+debut);
int nd = 0;
 
while (result.next()) {
     long d1 = System.currentTimeMillis();
     System.out.println("[d1 : " + d1 + "][debut : " + debut + "] " + (d1-debut) + "ms");
 
      ...
 
      long f1 = System.currentTimeMillis();
      System.out.println("temps traitement dossier "+(++nd)+" : "+(f1-d1)+" ms");
}

et voici ce qui est affiché dans la console :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
debut : 1209482828483
[d1 : 1209482837202][debut : 1209482828483] 8719ms
temps traitement dossier 1 : 0 ms
[d1 : 1209482837202][debut : 1209482828483] 8719ms
temps traitement dossier 2 : 0 ms
 
...
 
[d1 : 1209482837233][debut : 1209482828483] 8750ms
temps traitement dossier 29 : 0 ms
[d1 : 1209482837233][debut : 1209482828483] 8750ms
temps traitement dossier 30 : 0 ms

merci

[leminipouce]

Salut,

Je sais bien que normalement c'est ce qui est fait par défaut, mais est-ce que tu as essayé de faire un beforeFirst() sur ton ResultSet avant d'appeler next() ? Regardes combien de temps il prend pour faire le beforeFirst() ça pourait peut-être nous guider.

[in]

La requête de la procédure est assez complexe mais elle s'execute en moins de 30 ms à s'executer.

tu veux dire la méthode java executeQuery s'exécute en 30 ms ou dans TOAD ta requête ne prend que 30 ms ...

combien de lignes cette requete te retourne-t'elle ?

[KiLVaiDeN]

Salut,

J'ai l'impression que tu dois perdre beaucoup de temps sur ton premier next() car c'est à ce moment que Java crée l'objet "recepteur" de tes colonnes.

Si tes colonnes sont nombreuses et hétérogènes, le ralentissement peut être compréhensible, bien que je trouve ça étonnant.

Est-ce que tu utilises un pool de connexion ? Ton temps d'attente pourrait aussi être lié à une latence de connection. Essaie de voir si tu ne peux pas mettre un pool de connexion, qui garderait des connexions pour toi réservées d'avance, et qui éviterait le temps de latence à la connexion.

Donc selon moi, c'est plutôt le problème de connexion qui me parrait le plus probable, sauf comme je disais si tu retournes beaucoups de colonnes hétérogènes.

A+

[promopub]

Bonjour

merci de votre aide effectivement, le temps que je récupérais était celui du statement.execute() alors que les données sont récupérées lors du premier next().
Je pensais que ma requête mettais 30ms à s'exécuter alors qu'elle mettait 9000. J'ai résolu le problème qui se situait au niveau de la requête.

Voici les conclusions que j'ai tiré après recherche :

Le ResultSet obtenu en exécutant le statement (callableStatement.execute()) ne contient aucune donnée. C’est quand on fait le next(), que le ResultSet va rapatrier autant de ligne que définit dans le fetchSize.
Au prochain next() il utilise une des lignes rapatriées, jusqu’à ce qu’un next() nécessite des données non encore récupérées. On a alors un nouveau fetch().

Il est à noter qu’une obtention de ResultSet ne signifie pas que toutes les données a été récupéré et envoyé à votre JVM. Certains (beaucoup?) pilotes implémentent le ResultSet de manière à ce qu’on puisse commencer à récupérer certaines données dans le client alors que la base de données est encore occupée à trouver les données restantes sur le serveur. Ou alors que des données restantes continuent à être envoyés sur le réseau. Alors il ne faut pas penser que simplement parce que un executeQuery () a retourné que le traitement en base de données est effectué.

Augmenter la taille du fetch diminue le chargement sur la DB créé par la requête (pas forcément visible à l’œil nu mais visible dans les statistiques de la DB). Deuxièmement, cela diminue les aller/retour entre la DB et le client. Comme c’est un des facteurs limitant du processus, ca a un gros impact (moins que la qualité de la requête). Mais plus le réseau est rapide, moins cela à d’importance.
Plus gros fetch buffer = moins d’aller/retours = réponse plus rapide

Par défaut, Oracle utilise un fetch de 10, ce qui est généralement trop faible. Généralement 100 est une bonne valeur de test pour démarrer. La meilleur valeur dépends de la requête : pour des petites lignes un gros fetch, pour les grosses lignes un petit fetch. Généralement, les gens mettent la même valeur partout, il est inutile de faire des tests et des réglages pour toutes les requêtes. Il n’est absolument pas conseillé de choisir des valeurs trop grande (comme 100 000 par exemple), ce qui peut-être pire que la valeur par défaut et qui peut gêner les autres utilisateurs de la base.

Le réseau entre le client et la BD a aussi une interaction avec la taille du fetch. En général, l’augmentation de performance sera plus importante sur un mauvais réseau que sur un bon. Mais de mauvais réseaux peuvent travailler avec des grands fetch.