performances de rs.next()

**_Eric_** · 31/10/2007, 10h36

Bonjour,

En essayant d'optimiser mon appli j'ai mis en place un pooling sur l'interrogation d'une vue. Le but était de traiter un grand nombre de données par petits lots en pensant que ça irait plus vite et prendrait moins de mémoire.

Donc j'ai une requête de sélection (read only) sur une vue.
Quelque soit le nombre d'enregistrement la requête prend à peu près le même temps : 1 à 2s.
Par contre une fois la requête effectuée et le resultset obtenu je fais les resultset.next()... et c'est là que ça devient étrange :

moins il y a de tuple dans mon resultset plus le premier resultset.next est long !?!

exemple : il y a 1511 enregistrements dans ma vue
---------------------------+---------------------+----------------------
nombre d'enregistements.....| durée d'exécution.....| durée d'exécution
demandé parmis les 1511.....| de la requête...........| du 1er resultset.next
---------------------------+---------------------+----------------------
TOUS...............................|.................1031 ms |..................7631 ms
---------------------------+---------------------+----------------------
500.................................|...................711 ms |..................7540 ms
---------------------------+---------------------+----------------------
100.................................|...................601 ms |.................50493 ms
---------------------------+---------------------+----------------------
50...................................|...................611 ms |.................48900 ms
---------------------------+---------------------+----------------------

quelqu'un peut-il m'expliquer cela ?

JAVA 1.4
Base de donnée : SQL Server 2000 (vue sur une base liée : DB2)
Driver : net.sourceforge.jtds.jdbc.Driver

**OButterlin** · 31/10/2007, 12h05

Peux-tu mettre le code de ton traitement ?

A+

**_Eric_** · 31/10/2007, 13h42

voici un bout du code, bien qu'il n'y ai rien de particulier je pense :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
stmt = conn.createStatement();
stmt.setQueryTimeout(timeout*60*1000); // 12 mn
long start = System.currentTimeMillis();
rset = stmt.executeQuery(query);
System.out.println("createStatement " + (System.currentTimeMillis() - start));
start = System.currentTimeMillis();
while (!suspend && rset.next()) {
     System.out.println("rset.next() " + (System.currentTimeMillis() - start));
     ref = rset.getString("ref");
     ...
}

**OButterlin** · 31/10/2007, 14h03

Envoyé par _Eric_

... bien qu'il n'y ai rien de particulier je pense :

C'est le moins qu'on puisse dire...

mais je voulais être sûr que tu n'utilises pas de fonctionalités particulières des statements.

Le tableau de temps que tu as donné correspond à la lecture :
1- de tous les enregistrements
2- des 500 premiers enregistrements
3- des 100 premiers enregistrements
4- des 50 premiers enregistrements

ou faut-il comprendre :
1- idem
2- renvoi d'un bloc de 500 enregistrements (autres que les 500 premiers)
etc...

Je le demande parce que ça expliquerait le temps croissant (puisqu'il faudrait bien lire les enregistrements des blocs déjà lus)

Je suis clair ?

**_Eric_** · 31/10/2007, 14h13

il s'agit toujours des permiers enregistrement,
j'ai redémarré completement l'application entre chaque test

**_Eric_** · 31/10/2007, 14h14

et j'ai fais les tests plusieurs fois, avec des temps similaires dans chaque cas

**OButterlin** · 31/10/2007, 14h36

Alors là, c'est surprenant...
Dans ta boucle tu incrémentes un compteur et tu le testes, c'est bien ça ?
(ou tu utilises un setMaxRows(500)... )

**_Eric_** · 31/10/2007, 14h42

en fait la clause where de la requête est créé dynamiquement et ressemble à ça :

SELECT ... FROM ma_vue WHERE ref = 'x1' OR ref = 'x2' OR ...

avec autant de "ref = 'xn' OR" que de résultat attendu (tous, 1000 ou 500...).
ça peu sembler un peu lourd mais ça répond à mes contraintes de selection et le temps d'exécution de la requête me convient.
Mais je ne comprend ce délais pour le premier .next

**OButterlin** · 31/10/2007, 14h50

Ca veut dire que plus tu en demandes (hors tous), plus tu as de OR et ça met plus de temps ???

Peux-tu faire le test avec

Code :

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

1
2
 
 ref in ('x1', 'x2',..., 'xn')

**_Eric_** · 31/10/2007, 15h05

je vais essayer mais il me semblait que c'est la commande

Code :

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

stmt.executeQuery(query);

qui devrait être impactée par le temps de traitement de la requête.
le rset.next() ne fait que positionner le curseur sur le premier résultat non ?
A moins que le tableau de résultat ne soit effectivement créé qu'au premier next...?

Ca veut dire que plus tu en demandes (hors tous), plus tu as de OR et ça met plus de temps ???

non c'est le contraire
Et même lorsque je les demande tous j'ai toutes les references dans la clause where soit 1511 fois "ref='x' OR..." et ça va beaucoup plus vite que seulement 50 fois "ref='x' OR..."

**OButterlin** · 31/10/2007, 15h15

Oui je crois bien que c'est lors du premier next() qu'il va "lancer" la requête (physiquement) mais il fait déjà un contrôle lors de l'executeQuery (peut-être que syntaxique), dans tous les cas, ça risque fort de dépendre de ton driver JDBC...

Donc, moins tu en demandes, plus tu as de OR (on est d'accord) ?
Là, je comprends pourquoi ça met plus de temps...

Peux-tu en dire plus sur cette requête ?

**_Eric_** · 31/10/2007, 15h32

non c'est le contraire...

si je n'en veux qu'un seul (x1 par exemple) :
SELECT * FROM ma_vue WHERE ref = 'x1'

si j'en veux 10, je connais les 10 references (exemple : x1, x2, ..., x10) :
SELECT * FROM ma_vue WHERE ref = 'x1' OR ref = 'x2' [...] OR ref = 'X10'

Dans tous les cas je connais les références des tuples dont j'ai besoin.

en résumé :
- moins j'en demande, moins j'ai de paramêtre dans la clause WHERE et plus ça prend de temps
- plus j'en demande, plus j'ai de paramêtre dans la clause WHERE et moins ça prend de temps

in · 31/10/2007, 15h39

et si tu l'exécutes directement en SQL c'est la même observation ? Moins t'as de OR plus c'est long ?

quand tu dis que tu charge tout et que ça va plus vite, t'as pas un OR par ligne quand même ?

si oui, quel est le temps d'exécution de la requête SELECT * FROM mavue ?

sinon essaie de jouer sur les propriétés de ton statement en mettant par exemple en read-only, not scrollable ... Comme c'est sûr une vue, peut être que ça peut améliorer les choses ...

**_Eric_** · 31/10/2007, 15h52

et si tu l'exécutes directement en SQL c'est la même observation ? Moins t'as de OR plus c'est long ?

pour l'instant la base distante est indisponible, je testerai en sql lundi.

quand tu dis que tu charge tout et que ça va plus vite, t'as pas un OR par ligne quand même ?

si : [...] where ref='x1' OR ref = 'x2' ... OR ref = 'X1511'
c'est assez monstrueux mais ce cas où je demande tout n'est utilisé que pour les tests, en fonctionnement normal il y a en moyenne moins d'une dizaine d'enregistrement sélectionnés.
Et c'est parceque j'avais des temps de réponse pas terrible que j'ai élargit la requête à tous les enregistrements et que j'ai vu que ça allait mieux dans ce cas...

Concernant le statement il est créé avec les option par défaut :

Code :

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

stmt = conn.createStatement();

donc normalement TYPE_FORWARD_ONLY et CONCUR_READ_ONLY

**OButterlin** · 31/10/2007, 15h54

Envoyé par _Eric_

non c'est le contraire...

bon, on est sur la même longueur d'onde... désolé...

Quand tu dis "select * from ma_vue", c'est d'une vue que tu parles ou d'une table ?

**_Eric_** · 31/10/2007, 16h31

une vue

**OButterlin** · 05/11/2007, 08h32

Serait-il possible d'avoir la définition de la vue ?

**_Eric_** · 05/11/2007, 09h55

je n'ai pas la définition exacte de la vue, elle est fournie par une autre application.
Par contre cette vue est sur un environnement DB2.

pour répondre à "in" je vais faire le test en sql directement

**_Eric_** · 05/11/2007, 16h10

en exécutant les requêtes via "query analyser" de sql server le résultat semble "normal" donc contraire à ce que j'obtient en java :

pour 100 lignes : 14 sec
pour 500 lignes : 45 sec
plus il y a d'enregistrement et plus c'est long.

en exécutant les requêtes sous dos via l'interpreteur de commande DB2, c'est quasiment instantané quelque soit le nombre d'enregistrement demandé.

C'est vraiment dans le code java et en particulier lors du permier rset.next que c'est étrange.
Peut-être le driver ?

**OButterlin** · 05/11/2007, 16h16

Tu utilises quel driver ?

performances de rs.next()

JDBC Java

Discussions similaires

Partager

Partager