Montée en charge

[Hematia]

Bonjour,

Dans le cadre d'un assez gros projet de reporting, je cherche à savoir si BIRT régit bien à la montée en charge. Les tables dans lesquelles je vais aller chercher mes données sont de l'ordre de milliers d'enregistrements, et je vais commencer des tests pour voir comment BIRT réagit quand il faut traiter autant de données.

Néanmoins, j'aimerais connaître vos expériences dans ce cadre. Dans quel cadre vous utilisez BIRT, si la longueur du traitement devient trop longue, dans quelles conditions, etc..

Pour informations, ma base de données se trouve sur un as400, et j'utilise la version 2.3 de BIRT.

Merci d'avance

[helpmemorvan]

le gros souci de Birt c'est que tu passes par une connexion JDBC d'ou grosse perte de vitesse

pour donner un exemple sur un rapport qui interroge en SQL 5 tables avec clause where, group by, having (effectif des table 28,20 000,94 000*3)

j'ai la solution BO qui me met de 1 à 3 secondes pour m'éditer le rapport alors qu'avec BIRT c'est de l'ordre de 13 secondes cela est du évidemment au fait que BO à une connexion direct à oracle et ne passe pas par un JDBC.


edit: comme dit BiM un peu plus bas le problème de cache depuis la version 2.2.2 (il est quelque part mais ou ?)oblige du coup a réintérroger à chaque création de rapport la base

[BiM]

Bonjour,

Je fais du reporting sur des grosses bases.

Le temps de création d'un état varie en fonction :

• De la complexité du rapport
• Du nombre d'images et de graphiques
• Du type de DataSet et de la façon de les utiliser
• Des traitements internes au rapport
• Si les données sont stockées en cache ou pas (faut-il plutôt prendre sur l'espace mémoire ou sur le temps ?) PS : A partir de la V 2.2, je n'arrive plus à mettre les données en cache mais c'est visiblement toujours possible.

[Stefan C]

1) les pilotes JDBC Oracle ( Datadirect ou autres ) ont un performance à peine inférieure de 5% aux pilotes Natifs dans la plupart des requetes relativement simples.

2) le cache de BIRT n'est pas disparu. Bien au contraire , il vient d'être amélioré pour la montée en charge. Avant , une seule instance du cache existait pour toutes les instances du BIRT engine sur le serveur d'application ( disons Tomcat ). Maintenant vous avez une instance cache pour chaque appContext. Détails dans la documentation BIRT à partir du 2.2.

NB : le cache est maintenant géré de façon script + comment vous gérez les instances de BIRT Engine dans votre serveur d'application.

Si vous avez beaucoup d'users , je vous suggère de paralleliser. C'est a dire utiliser une instance de BIRT engine pour 20 users , une 2e pour les suivants 20 etc. Vous pouvez utiliser Jonas pour avoir un container "multi-Tomcat".

BO est très mauvais sur ce point , et ils ont une scalabilité misérable ( 40 users concurrents / CPU ) . Par contre , leur moteur de génération SQL utilise des algorithmes d'optimisation.

Vous n'avez pas ça dans BIRT , mais seulement du JDBC. Néanmoins , utiliser Hibernate ou Actuate Information Objects revient à avoir la même chose avec une gestion du cache. Ne pas confondre outil de reporting et outil de couche sémantique. Pour BO c'est pareil , ne pas confondre Desktop Intelligence et Universe Designer. 2 technos qui vont ensemble mais DIFFERENTES.

N'hesitez pas à me demander si besoin d'autres clarifications :-)

[Hematia]

En fait, mon souci, dans ce cas précis, n'est pas le nombre d'utilisateurs, mais surtout la quantité de lignes à remonter.

En parcourant les différents forums, j'ai cru comprendre que le traitement le plus long n'était pas forcément la liaison JDBC et la remontée des données depuis la table, mais plutôt la génération du rapport en html, pdf ou autre, dans le sens où le logiciel devait redessiner à chaque fois le design des pages, tableaux, donc les bordures, les images, etc..
De plus, les traitements internes à BIRT (par exemple, tri sur les données effectué par BIRT au lieu de la requête sql) semblent occasionner également un allongement de la génération du rapport plus élevé que prévu.

Est-ce que quelqu'un ici a déjà constaté un lenteur anormale ou gênante lors de génération de rapports ?

Quels sont les paramètres qui peuvent améliorer le temps de génération du rapport ?

[Stefan C]

1) Comment utiliser une seule connexion à la base : faire gaffe aux bindings. C'est beaucoup "moins" cher de reutiliser une donnée que de se reconnecter à la base. a cet effet , vous pouvez avoir un binding de type Y=datasetrow(X) et 1000 bindings Z1-Z1000 de type row(Y). Pareil pour les charts.

Faire le ménage dans les bindings pour chaque objet ( table , chart ) afin d'utiliser strictement le nécessaire.

2) Utiliser les aggrégations depuis la 2.2 à la place du Total.sum()

3) les trucs les plus couteux :

a) charts
b) groupes ( BIRT fais un tri automatique aussi sur un groupe , chose qui sera enlevée en 2.3 ). Pré trier vos données dans la requete SQL aide pas mal.
c) nombre de contrôles sur la page. Rajouter 20 images c'est très joli soit , mais pour les perfs...aie aie aie.

Sinon , je vais demander les benchs en pur open source , mais en commercial j'ai fait des rapports BIRT assez balaise qui ont mis 25 secs sur mon pauvre iServer sur mon laptop. Pour Info , ils avaient entre 3000 et 5000 pages. ( dans les 15000 rows ). Egalement , l'offre commerciale inclut un pilote IBM UDB , mais en théorie le pilote JDBC de IBM pour AS400 que vous utilisez devrait marcher pas mal à ma connaissance.

Enfin , si vos rapports cherchent dans les 100.000 - millions de pages , c'est pas avec BIRT ou un reporting open source que vous ferez l'affaire. Il vous faudra un outil de reporting de masse. La guerre sur ce marché se porte entre Actuate eReports et Crystal. Pour avoir utilisé les 2 , eReports c'est beaucoup plus puissant et performant, Crystal c'est plus convivial à développer mais manque certaines fonctionnalités.

[helpmemorvan]

Envoyé par cucubau123

1) Comment utiliser une seule connexion à la base : faire gaffe aux bindings. C'est beaucoup "moins" cher de réutiliser une donnée que de se reconnecter à la base. a cet effet , vous pouvez avoir un binding de type Y=datasetrow(X) et 1000 bindings Z1-Z1000 de type row(Y). Pareil pour les charts.

Faire le ménage dans les bindings pour chaque objet ( table , chart ) afin d'utiliser strictement le nécessaire.

euh j'ai pas bien compris ton histoire de Y=datasetrow(x) et X=row(y).

Quand tu dit faire le ménage tu veux dire supprimer les colonnes non incluses dans le rapport.

3000-5000 pages en 25 secondes
moi je met 15 secondes pour afficher une page doit y avoir une ******* quelque part

[Stefan C]

Je suis prêt à faire un Webex pour te montrer ces perfs :-) , C'est vrai que mon rapport de test était assez simple.

En attendant , tu peux m'envoyer ton adresse mail par MP , et je te ferais parvenir les best practices dans la matière. Je vais essayer de tout rassembler dans un PDF et le publier dans la section tutoriels.

PS : Enfin , 15 secondes / page , tu dois avoir au moins un gros chart bien complexe pour en arriver là , normalement :-)

[Stefan C]

Bonjour,

Pour ceux qui n'ont pas peur de l'anglais , voici un webinar gratuit sur Comment designer des rapports BIRT performants , présenté par un de nos experts BIRT.

http://www.birt-exchange.com//module...?cid=2&lid=347

Inscriptions ci-dessus.

[PNicoli]

Bonjour, suite à cette discussion concernant la montée en, charge, je me demande comment faire pour augmenter la limite en nombre de lignes de traitements ? Suffit-il d'augmenter la mémoire de la JVM ? Le cache ?

[BiM]

Bonjour,

Il n'y a pas de limite sauf dans le preview (littéralement prévisualisation et non visualisation (complète)).

Donc la réponse te renverrait à ce sujet : http://www.developpez.net/forums/sho...d.php?t=355207