Discussion :

[strusme]

Bonjour,

Je travaille sur une appli web Java qui peut se connecter à différent type de base (DB2 for iseries, Oracle...) ayant le même schéma (Utilisation d'Hibernate 3 --> Le code applicatif est le même).

J'ai des gros problèmes de perf sous DB2 (9 fois plus lent qu'Oracle pour le même traitement, par exemple : consolidation de 5000 enregistrements = 3 secondes sous Oracle et 33,5 secondes sous DB2).

Le driver JDBC que j'utilise est la version open source du jt400.jar


Ma configuration Hibernate :

<!-- Connection DB2 for iseries-->
<session-factory>
<property name="hibernate.connection.url">jdbc:as400://as400xxx;libraries=*libl;naming=system</property>
<property name="hibernate.connection.driver_class">com.ibm.as400.access.AS400JDBCDriver</property>
<property name="hibernate.connection.isolation">1</property>

<!-- configuration hibernate -->
<property name="show_sql">false</property>
<property name="format_sql">true</property>
<property name="hibernate.use_outer_join">true</property>
<property name="hibernate.query.substitutions">1</property>
<property name="hibernate.connection.autocommit">false</property>

<!-- configuration pool via c3p0-->
<property name="hibernate.connection.provider_class">org.hibernate.connection.C3P0ConnectionProvider</property>
<property name="c3p0.acquire_increment">3</property>
<property name="c3p0.idle_test_period">180</property> <!-- seconds -->
<property name="c3p0.max_size">100</property>
<property name="c3p0.max_statements">0</property>
<property name="c3p0.min_size">10</property>
<property name="c3p0.timeout">1000</property> <!-- seconds -->

Quelqu'un a une idée ?

[ALHER]

Salut,

Je pense que tu devrais demander à ton DBA de vérifier plusieures choses:

1- Le necessité de faire un RUNSTAT et peut-être une REORG sur les tables que tu utilise. La réorganisation des index devrait déjà améliorer les preformances.
2- Vérifier la taille des tablespaces pour les tables temporaires.

Dans ton application :

3- Vérifier le type d'accès a tes tables (Cursor Stability, repeatable read,...) et eventuellement modifier le code pour optimiser le blocage de pages dans les accès DB du programme.

4- Ajouter des COMMIT dans le code de façon à liberer les tables plus souvent

J'espère que ceci t'aidera à trouver une solutioin.

[Olivier Constans]

Les performances peuvent aussi grandement dépendre du type d'iSerie.

Les modèles anciens (avant le i5) n'étaient pas fait pour privilégier les traitements batch mais les interactifs et étaient particulièrement lents pour traiter des applications client/serveurs.

Si l'iSerie sur lequel vous vous connectez est un vieux modéle , cela peut expliquer les choses.

[strusme]

Je pense que mon problème vient du driver JDBC.

J'ai essayé des drivers JDBC différents mais sans succès.

J'ai même essayé via ODBC avec un pont jdbc:odbc (sun.jdbc.odbc.JdbcOdbcDriver) mais c'est encore pire.

Vous en pensez quoi ?

[alex.]

Bonjour,

Pourquoi penses-tu que ton problème provient de ton driver ? Si tu ne l'a pas déjà fait, je te conseilles de lancer des traces à la fois sur le client et le serveur. C'est le seul moyen de savoir où la différence de temps se passe.

Alex.

[strusme]

Je pense au driver parce que lorsque j'execute les requêtes directement sur la base les temps de réponses sont satisfaisants.

Mais tu as raison je vait faire parler le driver JDBC pour comprendre le problème.
Procédure à suivre pour cela : http://www-912.ibm.com/8625680A007CA...256A4200699408

Vous avez d'autres idées ?

[Olivier Constans]

Je pense au driver parce que lorsque j'execute les requêtes directement sur la base les temps de réponses sont satisfaisants.

Mais tu as raison je vait faire parler le driver JDBC pour comprendre le problème.
Procédure à suivre pour cela : http://www-912.ibm.com/8625680A007CA...256A4200699408

Vous avez d'autres idées ?

Directement sur la base, cela veux dire en mode interactif sur ecran 5250 avec strsql ?

Parce que dans ce cas cela rejoindrait mon idée initiale d'un as400 pas taillé pour traiter le batch.. mais plutot pour faire de l'interactif. Les travaux issus de client jdbc s'executent dans le sous systeme QSERVER et sont des travaux nommés QZDASOINIT de type BCI (batch par lot immédiat) . Regardez un peu comment est affectée la mémoire de votre as400 pour les sous systemes et la priorité données au travaux de type BCI.

J'utilise pour ma part le driver de jtopen 5.2 , je n'ai pas de soucis de performances dans mes appli java.

Mais bon en général, je passe par des appels de procédures stockées (le sql est natif dans ce cas ) ou alors je créée des index sur les tables iSeries que je dois exploiter si aucun fichier logique n'existe avec l'ordre de tri de mon sql.

[fred_crrm]

Bonjour,

J'ai aussi des problèmes de performances de ma connexion JT400 sur mon Iseries Model 800 en V5R2.

J'ai une application Java qui tourne sur une machine Intel et la même application qui tourne sur une partition Linux de notre Iseries.
La différence de performance est d'environ 1 à 5 en faveur de la solution Intel.

Après vérification, il semble que cette différence vient de la connexion JT400 pour écrire dans mes tables DB2. Hors, c'est exactement le même application qui est déployé sur les 2 systèmes, et vers le même Iseries.

Je pense que le paramètrage du JT400 ne donne pas le même résultat quand il est installé sur notre partition Linux, mais IBM ne sait pas nous expliquer le pourquoi du comment.

Pour information, nous avons installé une redhat 3.3 avec un noyau Linux 2.4.
La version Apache est 2.0.47 et la version Tomcat 4.1.30.

Merci d'avance pour votre aide

Fred

[strusme]

Apparement il existe un problème de compatibilité entre Hibernate 3.1 et jtopen 5.2 : http://opensource.atlassian.com/proj...owse/HHH-1479?

De plus jtopen ne sait pas gérer les prepareStatement : http://sourceforge.net/tracker/index...06&atid=712772