Discussion :

[mrjeronimo]

Bonjour,

Ma question est tte simple, sa réponse par contre peut nécessiter qlqs lignes de plus.

Je me demande si l'utilisation du mapping O/R basé sur Hibernate améliore la performance d'une application.

An effet, travaillant sur une appli Java/J2ee, je reçois régulierement des plaintes dénonçant la "lenteur" de l'appli. J'envisage donc plusieurs solutions dont celle de construire une couche DAO à la base d'Hibernate.

Pensez que cela contribuerait à l'amélioration de la performance de l'application?

Merci d'avance !

[fr1man]

Je ne pense pas que l'on puisse donner une réponse définitive à ta question.
D'un côté, Hibernate est une surcouche de JDBC, donc en thérorie, ça ne peut pas être plus rapide.
D'un autre côté, Hibernate peut être utilisé avec des systèmes de caches ce qui peut améliorer un peu les perfs.
Pour moi, si ton problème n'est lié qu'aux performances, Hibernate n'est pas la bonne solution.

[mrjeronimo]

Merci pour ta réponse fr1man

Oui c'est principalement un problème de performance. Personnellement je croyais que l'utilisation du mapping O/R qui réduit (corrigez moi si je me trompe) le nombre d'accès à la BD en persistant les données en mémoire (? à ma connaissance), pourrait eventuellement améliorer la performance de mon appli.

[dinobogan]

Quand il s'agit d'améliorer les performances, il ne faut jamais se mettre dans l'idée de toucher au code en premier. Il faut d'abord comprendre ou se situe le ou les problèmes. En fonction de ces découvertes, les bonnes décisions pourront être prises.
Est-ce un problème réseau ? La machine qui supporte la base de données est surchargée ? sous-dimensionnée ? etc...etc...

[mrjeronimo]

je suis tout à fait d'accord avec vous !

En effet, je m'occupe de la partie logicielle de l'application, par conséquent je dois apporter des explications pour affirmer ou infirmer le fait que la cause est la qualité du code produit ou l'architecture logicielle adoptée

[fr1man]

Personnellement je croyais que l'utilisation du mapping O/R qui réduit (corrigez moi si je me trompe) le nombre d'accès à la BD en persistant les données en mémoire (? à ma connaissance)

Cela peut réduire les accès à la base en utilisant les caches de niveau 1 et 2.
D'un autre coté, en JDBC pure, je suppose que si tu as besoin du numéro de ton client dans deux requêtes successives, tu vas garder le numéro en mémoire après le premier select et non faire deux select identiques.
Ceci dit, ça ne réduit pas les insert, update, delete, ça peut même les augmenter, selon comment à été faite l'application.

[dinobogan]

je suis tout à fait d'accord avec vous !

En effet, je m'occupe de la partie logicielle de l'application, par conséquent je dois apporter des explications pour affirmer ou infirmer le fait que la cause est la qualité du code produit ou l'architecture logicielle adoptée

Dans ce cas, je te donne une idée : une première approche par log des différents temps de traitements sur les différentes couches de l'appli. C'est suffisant et rapide pour cerner les gros bloc principaux qui posent problème. Mais attention à ne pas multiplier les logs de temps de réponse, car ça deviendrait vite le bazar dans le code. C'est seulement une "macro-approche".
Ensuite, il est possible d'identifier le code responsable, faire des tests unitaires et mettre au pilori le pauvre développeur qui à l'époque n'avait eu que quelques minutes pour coder 10000 lignes

[mrjeronimo]

Merci bcp pour vos réponses,

En résumé, je réctifie l'idée que le mapping O/R contribuera à l'augmentation de la performance (il me servira surtt pour mieux modulariser mon appli). D'autre j'utiliserai des logs pour obtenir des infos sur les temps de réponse par couche logicielle.

J'espère que ça me donnera une idée plus précise sur ce prob de perfs assez aberrant

[ZeRevo]

Avant de trouver une solution, il faut isoler ton problème.
Il faut commencer par valider la partie hardware pour s'assurer que le réseau et fiable et performant puis il faut valider la partie d'accès à la bdd (gestion des transactions...) et enfin le code en lui même.

[slevy]

Bonjour,

Tout dépend en fait de l'utilisation que l'on fait d'Hibernate. Le simple fait d'utiliser Hibernate ne va pas automatiquement améliorer les performances des accès aux données (c'est du SQL qui est généré au final).
Par contre, il est vital de bien comprendre comment Hibernate fonctionne, et pour améliorer les performances il faut :
- définir une "fetching strategy", c'est à dire pour chaque "use case" (chaque fonctionalité de l'application), choisir une manière optimale de récupérer les données en fonction de ce qu'on va en faire. Faut-il charger les données en "lazy" (si par exemple seule ne petite partie du graphe va être utilisé) ? Au contraire en "eager" ? En utilisant la fonctionnalité de "batch" (si on va afficher les données 10 par 10) ?
- utiliser le caching, tout en gardant à l'esprit que le caching de second niveau n'est utilisable que pour les données qui changent rarement, comme par exemple les données d'un outil de content management, qu'on peut invalider (au niveau du cache) toutes les 30 minutes.
Bref, les options sont nombreuses et plutôt complexes.
Le meilleur ouvrage sur Hibernate est sans aucun doute celui là :
http://www.manning.com/bauer2/

Il apporte des explications pour utiliser Hibernate de manière optimale.

Stéphane