Souci de perf + TopiaQuery
Bonjour à tous, Voilà, j'ai constaté que les méthodes findBy des DAO prenaient beaucoup de temps à l'exécution et augmentait au fur et a mesure. Sur un algorithme d'import d'un fichier contenant 85000 lignes, il est impensable d'avoir un temps qui augmente au fur et a mesure de l'appel au findBy. Pour m'en rendre compte, j'ai remplacé le findBy par une simple requête SQL (ou HQL ca marche aussi) avec Hibernate, et le temps d'exécution est instantané (grâce a un index sur la base) et n'augmente plus du tout dans le temps. Il y a donc un réel souci sur l'utilisation des Criteria d'Hibernate dans ToPIA. En parallèle j'ai travaillé sur une classe pour facilement construire une requête HQL (voir : http://nuiton.org/issues/show/178 ). Cette classe (TopiaQuery) est vraiment simple d'utilisation et permet de créer différentes requêtes plus ou moins complexe et d'interpréter précisément les résultats (type de retour). En essayant de remplacer toutes les utilisations des Criteria par cette classe, le temps d'exécution a fortement diminué, notamment sur une grosse exécution comme décrite plus haut. Alors l'idée, est-ce que ça vous convient de remplacer les criteria par l'utilisation de TopiaQuery ? A l'heure actuelle une version beta de TopiaQuery est sur le trunk. Elle a été légèrement modifié pour être plus souple au niveau des generic (notamment pour les retours au moment de l'exécution de la requête). Donc voilà, j'espère ne pas avoir été trop long, mais qu'en pensez-vous ? Cordialement, Florian
Le Tue, 29 Dec 2009 17:29:38 +0100, Florian Desbois <fdesbois@codelutin.com> a écrit :
Bonjour à tous, Bonjour,
Voilà, j'ai constaté que les méthodes findBy des DAO prenaient beaucoup de temps à l'exécution et augmentait au fur et a mesure. Sur un algorithme d'import d'un fichier contenant 85000 lignes, il est impensable d'avoir un temps qui augmente au fur et a mesure de l'appel au findBy.
Pour m'en rendre compte, j'ai remplacé le findBy par une simple requête SQL (ou HQL ca marche aussi) avec Hibernate, et le temps d'exécution est instantané (grâce a un index sur la base) et n'augmente plus du tout dans le temps. Moi je voulais rebondir là dessus, à mon avis c'est ton index qui fait gagner du temps et pas l'utilisation ou non des criterias. De toute façon si tu utilises des criterias ou des requêtes hql, le résultat devrait être le même en SQL.
Il y a donc un réel souci sur l'utilisation des Criteria d'Hibernate dans ToPIA.
En parallèle j'ai travaillé sur une classe pour facilement construire une requête HQL (voir : http://nuiton.org/issues/show/178 ).
Cette classe (TopiaQuery) est vraiment simple d'utilisation et permet de créer différentes requêtes plus ou moins complexe et d'interpréter précisément les résultats (type de retour). En essayant de remplacer toutes les utilisations des Criteria par cette classe, le temps d'exécution a fortement diminué, notamment sur une grosse exécution comme décrite plus haut.
Alors l'idée, est-ce que ça vous convient de remplacer les criteria par l'utilisation de TopiaQuery ? Tu vas pas réussir à avoir les mêmes possibilités que les criterias ou la syntaxe hql. Juste un exemple comment tu fais pour faire des jointures ou des sous-requêtes ?
A l'heure actuelle une version beta de TopiaQuery est sur le trunk. Elle a été légèrement modifié pour être plus souple au niveau des generic (notamment pour les retours au moment de l'exécution de la requête).
Donc voilà, j'espère ne pas avoir été trop long, mais qu'en pensez-vous ?
Cordialement,
Florian Julien
_______________________________________________ Topia-devel mailing list Topia-devel@list.nuiton.org http://list.nuiton.org/cgi-bin/mailman/listinfo/topia-devel
Le Thu, 31 Dec 2009 15:28:27 +0100, Julien Ruchaud <julien.ruchaud@codelutin.com> a écrit :
Moi je voulais rebondir là dessus, à mon avis c'est ton index qui fait gagner du temps et pas l'utilisation ou non des criterias. De toute façon si tu utilises des criterias ou des requêtes hql, le résultat devrait être le même en SQL. C'est une certitude de ta part ou juste une supposition ?
Il y a donc un réel souci sur l'utilisation des Criteria d'Hibernate dans ToPIA.
En parallèle j'ai travaillé sur une classe pour facilement construire une requête HQL (voir : http://nuiton.org/issues/show/178 ).
Cette classe (TopiaQuery) est vraiment simple d'utilisation et permet de créer différentes requêtes plus ou moins complexe et d'interpréter précisément les résultats (type de retour). En essayant de remplacer toutes les utilisations des Criteria par cette classe, le temps d'exécution a fortement diminué, notamment sur une grosse exécution comme décrite plus haut.
Alors l'idée, est-ce que ça vous convient de remplacer les criteria par l'utilisation de TopiaQuery ?
Tu vas pas réussir à avoir les mêmes possibilités que les criterias ou la syntaxe hql. Juste un exemple comment tu fais pour faire des jointures ou des sous-requêtes ? Ca me rappelle un peu Sandra avec des requêtes qu'on peut qualifier de monstrueuse,non Julien :) Dans tous les cas cela ne change rien à la problématique des DAO de ToPIA. Tu pourras toujours faire des requêtes de folies en récupérant la session hibernate, donc je vois le fondement de ton objection :) Il s'agi juste de remplacer l'utilisation des Criteria dans les findXXX dans les DAO générés qui n'utilisent
Le mieux c'est de regarde les requètes passées. dans tous les cas, je suis vraiment pour qu'on retravaille un peu les DAO de ToPIA car dans tous les cas le code n'est pas optimisé du tout... : remonter toute une partie de la base pour juste ensuite en java faire des boucles pour récupérer les résultats qui nous intéresse c'est pas top. Cela fonctionne tant qu'on a pas de gros volumes de données à traiter, non ? pas (je pense, mais j'en suis pas sûr...) de sous-requêtes ou jointure; j'espère ne pas me tromper ;) -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
De toute
façon si tu utilises des criterias ou des requêtes hql, le résultat devrait être le même en SQL. C'est une certitude de ta part ou juste une supposition ?
Le mieux c'est de regarde les requètes passées.
Et bien au vu des tests de perf, les criteria sont plus long a l'execution sur un Thread qui tourne en boucle qu'avec de simple HQL, index de base ou non.
dans tous les cas, je suis vraiment pour qu'on retravaille un peu les DAO de ToPIA car dans tous les cas le code n'est pas optimisé du tout... : remonter toute une partie de la base pour juste ensuite en java faire des boucles pour récupérer les résultats qui nous intéresse c'est pas top. Cela fonctionne tant qu'on a pas de gros volumes de données à traiter, non ?
En fait ca va les criteria était assez optimisé au niveau requetage pour les DAO, alors pour la durée d'execution je suis toujours dubitatif... Le problème vient vraiment de la limitation des méthodes proposés, de simple findBy ne suffisent pas toujours... D'ou l'interet d'utiliser un systeme de requetage comme TopiaQuery, simple et complet
Alors l'idée, est-ce que ça vous convient de remplacer les criteria par l'utilisation de TopiaQuery ? Tu vas pas réussir à avoir les mêmes possibilités que les criterias ou la syntaxe hql. Juste un exemple comment tu fais pour faire des jointures ou des sous-requêtes ?
En fait le principe du TopiaQuery, c'est que tu manipule une requete HQL donc, t'en fait ce que tu ve, tu peu la construire comme tu ve donc aucun probleme pour les jointures ou les sous-requetes, ce sont simplement des bouts de HQL.
Ca me rappelle un peu Sandra avec des requêtes qu'on peut qualifier de monstrueuse,non Julien :) Dans tous les cas cela ne change rien à la problématique des DAO de ToPIA. Tu pourras toujours faire des requêtes de folies en récupérant la session hibernate, donc je vois le fondement de ton objection :)
Heu certes récupérer la session hibernate permettrait d'utiliser les Criteria, mais alors l'application cliente devient fortement dépendante d'Hibernate...
Il s'agi juste de remplacer l'utilisation des Criteria dans les findXXX dans les DAO générés qui n'utilisent pas (je pense, mais j'en suis pas sûr...) de sous-requêtes ou jointure; j'espère ne pas me tromper ;)
La dessus aucun souci, le gain de vitesse d'exécution est flagrant dès qu'on utilise directement du HQL plutot que des Criteria ! Reste a savoir pourquoi ! Sur ce, je pense commité sur Topia ces quelques modifs : - Passage du TopiaQuery en generic (la requete doit toujours au minimum tapé sur une table/entité pour être exécuté) avec methodes static pour instanciation. - Remplacement de l'utilisation des Criteria dans TopiaDAOImpl par l'utilisation du TopiaQuery. - Ajout de methodes dans le TopiaDAO (interface) pour crée simplement des instances de TopiaQuery correspondant a l'entité du DAO, pour etre ainsi manipulé aisément dans l'application cliente : ex : SampleRowDAO dao = SuiviObsmerModelDAOHelper.getSampleRowDAO(transaction); TopiaQuery<SampleRow> query = dao.createQuery().add(SampleRow.CODE, Op.LIKE, year + "_%"); ... Pour clore le débat, sur un import d'un CSV de 86000 lignes, je suis passé de plus de 10h d'execution en utilisant les anciens findBy (Criteria), à 2min en utilisant du HQL.
C'est une très bonne chose tout ça je pense. Le 04.01.2010 11:26, Florian Desbois a écrit :
- Remplacement de l'utilisation des Criteria dans TopiaDAOImpl par l'utilisation du TopiaQuery.
Cette remarque me fait lever une nouvelle interrogation : A quel pourcentage Topia est-il dépendant d'Hibernate ? Si je prends l'exemple de Spring (et plus particulièrement spring-orm), il n'est pas dépendant d'Hibernate. La dépendance dans le pom est en <optional>true</optional> au même titre que Toplink et Ibatis. Est-ce qu'une telle chose est envisageable sur Topia ? Est-ce que c'est ce que nous souhaitons ? Arnaud. -- Société Code Lutin http://www.codelutin.com tel : 02 40 50 29 28 fax : 09 59 92 29 28
Le lundi 04 janvier 2010 à 11:36 +0100, Arnaud Thimel a écrit :
C'est une très bonne chose tout ça je pense.
Le 04.01.2010 11:26, Florian Desbois a écrit :
- Remplacement de l'utilisation des Criteria dans TopiaDAOImpl par l'utilisation du TopiaQuery.
Cette remarque me fait lever une nouvelle interrogation :
A quel pourcentage Topia est-il dépendant d'Hibernate ?
Si je prends l'exemple de Spring (et plus particulièrement spring-orm), il n'est pas dépendant d'Hibernate. La dépendance dans le pom est en <optional>true</optional> au même titre que Toplink et Ibatis.
Est-ce qu'une telle chose est envisageable sur Topia ?
C'est possible je pense ! Il n'y pas tant de classe que ca qui sont dépendantes d'Hibernate, et si on modifie tous les requetages par l'utilisation de TopiaQuery cela réduira fortement le couplage !
Est-ce que c'est ce que nous souhaitons ?
Et bien cela facilitera le passage a JPA, mais il faudra tout de meme modifier la génération pour le mapping !
Arnaud.
Le Mon, 04 Jan 2010 11:36:07 +0100, Arnaud Thimel <thimel@codelutin.com> a écrit :
C'est une très bonne chose tout ça je pense.
Le 04.01.2010 11:26, Florian Desbois a écrit :
- Remplacement de l'utilisation des Criteria dans TopiaDAOImpl par l'utilisation du TopiaQuery.
Cette remarque me fait lever une nouvelle interrogation :
A quel pourcentage Topia est-il dépendant d'Hibernate ?
Si je prends l'exemple de Spring (et plus particulièrement spring-orm), il n'est pas dépendant d'Hibernate. La dépendance dans le pom est en <optional>true</optional> au même titre que Toplink et Ibatis.
Est-ce qu'une telle chose est envisageable sur Topia ? Est-ce que c'est ce que nous souhaitons ?
oui +1 : mais pas pour l'instant... Je pense qu'on doit d'abord : - migrer l'api sur JPA - quand ça marche bien, migrer les mappings sur JPA Puis ensuite mettre en place le choix d'implentation à choisir (ça devrait être simple avec JPA :))
Arnaud.
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
On Mon, 04 Jan 2010 11:26:22 +0100 Florian Desbois <fdesbois@codelutin.com> wrote:
Dans tous les cas cela ne change rien à la problématique des DAO de ToPIA. Tu pourras toujours faire des requêtes de folies en récupérant la session hibernate, donc je vois le fondement de ton objection :)
Heu certes récupérer la session hibernate permettrait d'utiliser les Criteria, mais alors l'application cliente devient fortement dépendante d'Hibernate...
Sans recupere la session, le TopiaContext permet deja de faire des requetes (y'a la methode pour). Pour ce qui est de TopiaQuery, il faut faire attention a ne pas faire une usine a gaz, ni faire tu trop specifique (liaison de l'application client avec hibernate), ni re-ecrire ce qui existe deja et qu'on a abandonne (LutinQuery). Je vais regarder l'implantation (j'ai mis ca dans ma todo list, car dans le train j'ai pas les sources :)) Mais pour des raisons de performance, si on arrive a faire un TopiaQuery avec des methodes statiques (donc sans instanciation) se serait le mieux. -- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii
participants (6)
-
Arnaud Thimel -
Benjamin POUSSIN -
Florian Desbois -
Jean Couteau -
Julien Ruchaud -
Tony Chemit