Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 2 sur 2
  1. #1
    Membre éclairé
    Inscrit en
    mars 2004
    Messages
    373
    Détails du profil
    Informations forums :
    Inscription : mars 2004
    Messages : 373
    Points : 311
    Points
    311

    Par défaut [JDBC] Problème de performance

    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.

  2. #2
    Membre actif
    Homme Profil pro Eric Vercelletto
    Achitecte Informix SGBD et applications - IBM Champion - Data Management - Board of Directors IIUG
    Inscrit en
    octobre 2010
    Messages
    101
    Détails du profil
    Informations personnelles :
    Nom : Homme Eric Vercelletto
    Âge : 54
    Localisation : France, Finistère (Bretagne)

    Informations professionnelles :
    Activité : Achitecte Informix SGBD et applications - IBM Champion - Data Management - Board of Directors IIUG
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2010
    Messages : 101
    Points : 155
    Points
    155

    Par défaut

    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

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •