Discussion :

[Morbo]

J'essaie d'utiliser BIRT pour l'édition des bulletins de salaire de ma boite.
La source de donnée est un fichier xml petit et peu complexe, il y a juste un nombre de poste de paie variable.
Le bulletin pdf doit pouvoir gérer plusieurs page en répétant l'entete et le bas de page.
Je pense avoir fait ce projet de façon correcte, mais j'ai un pb de perf évidente : un bulletin de 2 pages, met 15 à 20 sec à se générer.
J'ai quelques colonnes dynamiques mais j'avais les même perf avant.
J'ai testé avec la preview du designer ou sur un tomcat avec le runtime de birt et j'ai pas constaté de gain en perf.
Des idées?

[BiM]

Bonjour,

Le premier démarrage du moteur est long mais ensuite la génération de page est assez rapide en général.

Fais attention que tu ne redémarres pas le Report Engine à chaque génération, sinon t'en a pour 2 ou 3 siècles

[Morbo]

Bonjour,

Sur tomcat il n'y a pas raison que le report engine soit redémarré à chaque appel, enfin je ne vois pas pourquoi et je ne fais rien pour que ce soit le cas.
Est-ce que chaque modification au report implique une recompilation ou generation quelconque qui fait perdre du temps?

[BiM]

Non mais si tu fais engine.destroy() ou un truc dans le genre, ben ca redemarre a chaque fois

[Morbo]

Pour le coup, j'utilise même pas java, je fais appel à la servlet du birt engine "birt/frameset?__report=bulletin.rptdesign&__format=PDF" avec le navigateur.
J'ai testé successivement plusieurs fois le même appel, la premiere fois 3 minutes, et 40 secondes tous les appels successifs.
Je peux vous fournir le report et le xml que je parse si ça peut vous aider à voir pourquoi j'ai de telle perf. Je veux bien faire mes appel en java, mais seulement si ça améliore les perf car faudra que j'adapte pas mal mon architecture, là c'était pas mal découplé.
Merci de votre aide en tout cas .

[Morbo]

Bonjour,
Actuellement j'ai l'architecture suivante :
Cocoon (framework web basé sur xml/xslt) sert de frontend web, et mes bulletins sont générés par Birt qui se base sur un seul et même projet .rptdesign .
Pour chaque bulletin seul le chemin vers la source de donnée (fichier xml) va changé. Je me servais jusqu'à maintenant de cocoon pour créer un nouveau .rptdesign temporaire avec le bon chemin (très simple avec cocoon) puis je faisais un appel web à la servlet standard de Birt pour générer le pdf.

Si re-design mon architecture en créant une servlet spécifique pourrai-je ne charger le projet qu'une fois et simplement changer le chemin de la source de donnée? Vais-je gagné en perf?
Est-ce que c'est cette étape qui est lourde en cpu?

De même j'ai certaines colonnes calculées dans Birt, mais je peux tout aussi bien les calculer en amont (XSLT) si Birt n'est pas performant dans cette tâche.

Un exemple de mon projet et d'une source xml est disponible sur ce post : http://www.developpez.net/forums/sho...45&postcount=7

[BiM]

J'ai remarqué en essayant ton exemple la dernière fois un gros problème de lenteur en effet. Je me demandais si tu avais essayé de faire la même chose à partir d'une petite base de données pour voir si ca vient de la connexion ou du design.

[Morbo]

Je vais finir par faire ce test.
En tout cas, plus ça semble 2 fois plus long quand on passe de 1 pages à 2.

[Morbo]

En passant à 2 fichiers csv à la place du fichier xml, je passe à :

• 3 sec pour une page, contre 20 sec.
• 5 sec pour 2 pages contre 40 sec.

Mais le xml est supposé être mon format d'échange standard, je vais avoir du mal à adapter mon architecture.
Ou alors j'ai fait une bourde dans le binding xml?

[BiM]

Peut être qu'avec un fichier qui indique le schéma du XML, ca ira plus vite.

[Morbo]

Je sais pas comment fonctionne Birt, mais les schémas XML c'est juste pour pouvoir valider des xml conformément à un modèle.
Les accès semblent être géré en XPATH.
Je vais peut être repartir sur fop :-/.

[BiM]

Je sais pas comment fonctionne Birt, mais les schémas XML c'est juste pour pouvoir valider des xml conformément à un modèle.
Les accès semblent être géré en XPATH.
Je vais peut être repartir sur fop :-/.

Sans ca, tu peux faire le traitement de tes données avant génération afin de faire des Scripted Data Set, dans ce cas là, tu utilises une autre méthode de parsing XML que tu gères toi même. Ca te permet aussi d'en changer au cas où tu trouverais plus performant.

Mais c'est quand même étrange. Les résultats dans le Preview du Data Set sont bien plus rapides comparés aux résultats dans le Preview du Report.

[Morbo]

Apparemment c'est un bug "résolu" de perf : https://bugs.eclipse.org/bugs/show_bug.cgi?id=140773
Connu depuis mai 2006 :
http://dev.eclipse.org/newslists/new.../msg09191.html
Apparemment, faudrait limiter le nombre de colonnes par dataset et le nombre de dataset par xml . En gros perdre l'intéret des arbres du xml pour faire des fichier csv.

Et en effet, ça peut se contourner avec des Scripted Datasets, mais bonjour l'evolutivité.
Chaque fois que mon xml va évoluer, je serai obliger de retoucher et compiler ma classe java custom. A moins de trouver quelquechose de générique.

Sinon faudrait que je pousse un peu mon convertisseur rptdesign -> xsl-fo, vu que le pdf en sortie peut me suffire.

[BiM]

Oui mais finalement il n'a jamais été vraiment résolu si tu lis jusqu'au bout.

Pour plus d'infos pour réduire ton temps de chargement :
http://www.developpez.net/forums/arc.../t-271365.html

D'autre part, j'ai trouvé une discussion sur le newsgroup de BIRT, c'est un français qui avait eu le problème : http://dev.eclipse.org/newslists/new.../msg10854.html

Si tu as le courage, tu peux peut-être leur proposer d'implémenter une autre méthode de parsing au XML Data Source.