Discussion :

[rsc]

Bonjour à tous ! Je suis nouveau avec Birt et je reprends les états élaborés par un collègue.

J'ai une source de données Oracle (serveur sur réseau local). Et à chaque fois que j'ouvre la fenêtre de propriétés d'un jeu de données (peu importe lequel) je dois attendre entre 30 s et 2 mn , alors que l'exécution de la requête elle-même, soit en prévisualisation des données, soit en aperçu de l'état, est quasi instantanée.

J'en viens à penser que ce qui est long, c'est la recherche des Users que la fenêtre affiche sous le nom d'"éléments" disponibles, ce dont je n'ai pas besoin, en tous cas en routine.

Quelqu'un connaît-il un moyen d'éviter ces temps d'attentes à répétition ?
Merci d'avance

[BiM]

Bonjour,

Il faudrait voir comment sont composés tes paramètres peut être, tu me dis que ta requête seule ne prend pas autant de temps, as-tu testé via le connecteur que tu utilises ou directement dans un client SQL ou sur le serveur SQL ?

/!\ Attention, en prévisualisation, seules les premières lignes du jeu de données sont affichées (voir les préférences de prévisualisation).

[rsc]

Merci !

- Ma requête ne renvoie qu'une ligne,
- Je l'ai testée en direct (dans SQLDeveloper)
- Elle ne pose aucun problème de temps en exécution dans Birt Viewer

et si on ajoute que la lenteur est la même pour tous les jeux de données de tous les états,

cela explique pourquoi je m'oriente vers un problème spécifique à l'ouverture de cette fameuse fenêtre de propriétés de jeux de données et pourquoi j'ai pensé à un temps de latence lié à l'exploration de tout le contexte de l'instance Oracle.

A vrai dire, je ne comprends pas pourquoi, alors que ma connexion utilise un user qui n'a des droits que sur un schéma, j'accède à toute une liste de schémas systèmes ou autres utilisateurs...

[BiM]

Ah au fait, t'oublies un paramètre. A la première instance du moteur BIRT, il se passe plusieurs secondes pour que celui-ci démarre (tout dépend des performances de ton PC). Et je me demande même s'il ne l'instancierais pas à chaque fois en mode preview pour le détruire une fois la preview affichée.

[rsc]

Ma machine est un i5 à 3.33 Ghz avec 4 Go de RAM.

Je n'ai pas bien compris ce qu'il chercherait à instancier.

A part ça, je viens d'avoir l'idée d'essayer de créer un nouveau jeu de données (requête de sélection SQL), et j'ai les mêmes temps d'attente à l'ouverture de la fenêtre !

[BiM]

Alors une génération BIRT se déroule en plusieurs temps :

1. Instanciation du moteur BIRT
2. Génération du document
3. Rendu du document au format final

Les étapes 2 et 3 sont dans le cas d'un preview faites ensemble. Par contre, l'instanciation lance le moteur de BIRT sur une plateforme OSGi pour ensuite s'en servir. Le lancement d'un tel élément prend un peu de temps. Cependant, lorsque tu gères toi-même ton moteur (avec l'API Java), tu peux faire en sorte qu'il soit instancié une fois pour toutes, et tu le réutilises à chaque fois que tu veux sans le réinstancier à chaque fois.

C'est pour cela qu'en prévisualisation, cela peut te paraître un peu lent.

(Ceci dit, 30 secondes à 2 minutes, ca me paraît long pour le coup)

As-tu le même comportement sur un nouveau rapport ?
As-tu le même comportement lorsque tu essayes d'accéder à la base de données exemple (Classic Models) ?

[rsc]

As-tu le même comportement sur un nouveau rapport ?

Exactement !

As-tu le même comportement lorsque tu essayes d'accéder à la base de données exemple (Classic Models) ?

J'ai l'impression qu'elle ne fait pas partie de notre installation de Birt (j'ai d'installé le RCP Designer, et le Viewer comme plugin de Tomcat).
Par contre, je viens de faire deux essais (les deux avec mon nouvel état vierge) :
- connexion à une base Oracle (autre instance sur autre serveur), les temps restent les mêmes;
- connexion à une base Firebird (serveur en local) : c'est immédiat.

[lazarel]

Tu as soit un problème de réseau, soit un problème via ton driver JDBC si celui-ci n'est pas de type 3 dans ce cas tu risque d'exploser le nombre de connexion à ton serveur Oracle car celle-ci ne seront pas fermées.

[BiM]

As-tu un autre driver pour te connecter à ta base ?

[rsc]

Notre réseau n'est sans doute pas au top, mais d'une part, je n'y peux pas grand-chose , d'autre part, étant donné les temps constatés via SQLDeveloper, le noeud du problème ne me semble pas être là.

En ce qui concerne le driver de classe 3, comment est-ce qu'on reconnait un driver de classe 3 ? et où en trouve-t-un le cas échéant ?
J'utilise actuellement un driver contenu dans classes12.zip : oracle.jdbc.OracleDriver(1.0)

[lazarel]

Il y a un lien ici. Par contre je sais plus si c'est type 3 ou 4.

L'idée étant la suivante: si dans ton driver la méthode close ne ferme pas la connexion celle-ci reste ouverte. Tu peux donc lancer tes rapports quelques fois au début mais après tu auras une exception comme quoi il y a plus de connexions disponibles.

Si tu n'as pas ce genre de problème, il faut chercher ailleurs

[BiM]

Tu n'aurais pas aussi ce driver par hasard : oracle.jdbc.driver.OracleDriver ?

Si oui, peux-tu essayer avec ?
Sinon, il doit se trouver dans le JAR ojdbc14.jar.

Pour info : http://www.developpez.net/forums/d77...n-base-oracle/

EDIT : Et plus... http://serverfault.com/questions/104...and-ojdbc6-jar
(Il me semble que BIRT est compilé en Java 5)

[rsc]

Merci à tous les deux pour les liens !

@lazarel : Comme expliqué plus tôt, la lenteur survient, non pas à l'exécution d'un rapport, mais à l'ouverture de la fenêtre de création ou d'édition d'un jeu de données dans RCP Designer, et cela dès la première fois.

@BiM : Je viens d'essayer avec ojdbc14.jar et le driver dont tu parlais, même problème.

NB : Juste un "détail" que j'ai oublié de préciser : nous sommes en version 2.30 aussi bien pour le Viewer que pour le Designer. Et pour des questions de déploiement chez les clients, il faudra que je fasse avec en tous cas pour un moment

[lazarel]

Tu as cette lenteur si tu veux afficher la prévisualisation des données seulement ?

[rsc]

@lazarel

Non, à l'ouverture de la fenêtre, et même en cas de création d'un nouveau jeu, à un moment où la requête n'existe même pas, on a simplement précisé quelle source de données on va utiliser ! Ensuite, la prévisualisation des données répond bien aux délais qu'on peut escompter, suivant la complexité des requêtes.

En gros, mon idée, en ouvrant la discussion, c'était : "Le problème est dû au "chargement" de tous les schémas de l'instance. Existe-t-il un moyen de dire au Designer : Inutile de me rechercher tous les schémas, puisque le User sous lequel je me connecte n'a de droits que sur son seul schéma !"

[lazarel]

Dans ce cas, il s'agit d'un problème coté base de données. Tu dois utiliser un utilisateur qui n'a accès et ne doit voir que ce dont il a besoin

Demande à ton DBA

[BiM]

Heu, et normalement, dans ton URI pour accéder à la base de données, tu peux aussi préciser le schéma.

[rsc]

@BiM
Je ne pense pas. En fait dans Oracle, les notions de User et Schema se superposent (contrairement à PostgreSQL par exemple). D'après ce que j'en comprends, un schéma n'est que l'ensemble des objets appartenant à un User.

@Lazarel
Mon User n'a que CONNECT et RESOURCE comme rôles. Difficile de faire moins. En fait, je vois les autres Users, mais pas leurs objets, sauf quelques exceptions (pourquoi, je ne sais pas et n'ai pas beaucoup le temps d'approfondir).

Bon, vu qu'il ne semble pas y avoir de solution simple je pense que je vais arrêter de vous ennuyer avec ça. A chercher à ne pas perdre 1 ou 2 mn d'attente, on va finir par y passer des heures

Merci pour vos efforts !

[BiM]

Mais l'utilisateur n'est pas obligé d'avoir les droits sur tous les schémas.

Et normalement, en Oracle, tu peux préciser le schéma comme suit :
jdbc:oracle:thin:<schema>@<server>:<port>:<SID>
(A vérifier tout de même)

[rsc]

Oui, on peut effectivement, mais c'est juste une manière alternative de passer la paire user/password.

http://www.oracle.com/technetwork/da...281.html#05_04

Je viens de tester, ça ne change absolument rien

Quant à avoir les droits sur tous les schémas, non bien sûr, mais les voir, si apparemment, à moins que nos serveurs soient installés d'une manière tout à fait spéciale, mais si c'est le cas, notre DBA l'ignore

Ceci dit, je me suis dit que cet affichage était la cause de la lenteur, parce que c'est la seule chose visible qu'il fait à part se connecter à la base, mais c'est peut-être tout à fait autre chose.