[JDBC] Problème de performance

[ZeKiD]

Bonjour à tous les pro d'Informix,

Voilà j'ai un problème assez génant.
Je suis en Java 6 avec le driver JDBC 3.5JC3 d'Informix.
J'effectue un SELECT * FROM MATABLE qui me renvoit environ 9000 lignes.
Le nombre de colonnes est de 40.

Le problème est qu'en bouclant sur l'ensemble des lignes. Cela prend un peu plus de 8secondes. Ce qui vous pouvez le confirmer est énorme. Surtout en ne faisant absolument rien d'autre que de boucler par la méthode ResultSet.next().

Je sais d'expérience qu'en Oracle, on peut utiliser setFetchSize qui permet de dire que pour un appel à rs.next(), on récupère "n lignes". Ce qui permet d'alléger considérablement le nombre de requete réseau à la base.
Il semblerait que ce ne soit pas le cas avec Informix.
Cf ici : http://publib.boulder.ibm.com/infoce...c2/jdbcdoc.htm

En lisant la doc, je comprend qu'il y a quelque chose qui s'appelle DIR_NEXT et qui permettrait de régler ce problème. Simplement je ne sais pas ce que sait, ni même où modifier cette chose.
Donc si quelqu'un a déjà eu ce problème, ou bien si quelqu'un sait ce qu'est ce DIR_NEXT, je vous serai très reconnaissant si vous pouviez m'aider.
Je pense qu'ici les pros, çà ne manque pas, donc je compte sur vous.
J'ai beau cherché sur Google, rien ....
Mille mercis d'avance,

Cordialement,

Zekid.

[begooden-it]

Bonjour,

il n'a pas fallu attendre Oracle pour implémenter chez Informix ce genre de solution. La variable d'environnement FET_BUF_SIZE sert à maximiser le transport des rangées sur le réseau entre l'application et l'instance Informix en agrandissant la taille des paquets tcp, afin de limiter le nombre d'aller-retour entre l'instance et l'application.

La valeur par défaut est de 4Kb, le minimum étant 1 Kb et le maximum 32 Kb.

Il faut donc, dans votre cas, trouver une valeur supérieure à 4 Kb et inférieure à 32Kb ( à exprimer en octets ex 16384 ), la meilleure méthode étant par approximation: modifier la valeur, arrêter le moteur, redémarrer, lancer la requête et mesurer. 16 Kb parait être un bon point de départ.

D'autre part, le SELECT * est-il vraiment nécessaire? Il est vrai que l'on écrit plus rapidement "SELECT *" que "SELECT col1,col2....col65" , mais ceci s'appelle souvent de la flemme stupide, qui fera peut-être gagner 10 secondes au développeur, mais certainement pas 10 secondes en production, bien au contraire!

Ne sélectionner que les colonnes nécessaires est une pratique qu'il faut mettre en oeuvre en permanence, car elle limite, dans le cas où toutes les colonnes ne sont pas indispensables pour l'appli, le trafic réseau et peut améliorer fortement la performance.

D'autre part, avant de se lancer dans des modifs, il convient de voir si c'est bien le nombre d'aller-retours appli-serveur qui est la root-cause du problème de performance, et non pas un index mal calculé par exemple. Pour ce faire, il faut tester un scénario de ce genre:

Code :

1
2
3
4
time dbaccess mabase <<!
output TO /dev/NULL
SELECT * FROM matable
!

Si le temps obtenu est radicalement inférieur à celui obtenu sous JDBC, il est probable que la modification de FET_BUF_SIZE apportera un gain. Sinon il faut regarder du côté du plan de requête ( set explain on ).
A considérer très sérieusement dans les développements avec JDBC, dont les données passent systématiquement par le réseau.

Chercher les causes avant de se lancer dans l'application d'une solution

Hope this helps

Eric