La restitution est le résultat du travail acharné de la MOA, MOE et des développeurs. Le choix de l’outil pour créer et afficher cette restitution est toujours difficile.
Pour la restitution nous avons misé sur la solution Jaspersoft. Nous avons actuellement la version 3.7 professionnelle.
Après un an de développement de rapports, nous avons été forcés de constater que notre plateforme de développement n’était pas toujours très stable.
Avant de mettre les rapports en production, nous avons fait intervenir un architecte afin qu’il fasse des tests de montée en charge. Le but étant de pouvoir agir en conséquence soit sur la base de données, soit sur le matériel, l’application TOMCAT…
Afin de réaliser les tests, nous lui avons fourni un rapport d’une dizaine de pages, d’une dizaine de sous rapports à exécuter.
Le temps nominal d’exécution de ce rapport était de 7 secondes. L’architecte a donc simulé l’attaque du serveur par plusieurs utilisateurs qui exécuteraient en même temps ce rapport. Il a joué sur plusieurs paramètres : la fréquence, le nombre de rapports exécutés en même temps.
Lors de la génération de 10 rapports de ce genre en même temps le temps de réponse s’en est trouvé très fortement dégradé et certaines des demandes ne sont pas traitées et renvoyées directement en échec.
L’architecte s’est rendu compte que Jasperserver :
- ne permet pas de limiter le nombre de rapports générés simultanément
- ne permet pas d’isoler l’IHM et le traitement des rapports
- ne dispose pas de mécanisme de file d’attente
Si le serveur ne tombe pas actuellement dans ces conditions, c’est grâce à un nombre de pool de connexion limité à 5 dans les fichiers de configuration de Jaspersoft.
Nous avons donc contacté Jaspersoft avec l’architecte. Pour pallier à ces problèmes ils nous ont donc recommandé d’augmenter la JVM dans TOMCAT(configurer JAVA_OPTS dans <TOMCAT>/bin/setclasspath.sh) ainsi que d’augmenter la puissance de notre hardware.
Ces problèmes Jaspersoft les traitera dans les prochaines versions. En attendant il faudra passer par un fork en faisant appel à des solutions standards pour ajouter les options que Jasperserver ne gère pas actuellement. En effet nous avions proposé de développer une solution chez nous puis de la reverser à la communauté mais leur système de validation à l’air très compliqué et cela pourrait prendre trop de temps à être accepté. Ils préfèrent développer ces options en interne.
Voici l’architecture finalement attendue :
26 avril 2010 à 11 h 07 min
Coucou Maryam,
Un fork? Que veut dire ce mot savant?
27 avril 2010 à 7 h 59 min
Salut Sonia,
Un fork est un développement fait sur l’application qui ne sera pas reversé à la communauté. Ce développement ne sera donc pas intégré en tant que tel dans les versions futures de l’application.
22 juin 2010 à 11 h 24 min
Je précise qu’un fork peut très bien être reversé à la communauté, c’est d’ailleurs obligatoire avec certaines licences open source …
Les forks deviennent parfois des produits à succès !
21 juillet 2010 à 20 h 18 min
Bonjour,
Article très intéressant.
Me concernant, dans ma société, nous sommes en train d’analyser cette solution et nous sommes tombés sur les mêmes constats.
Cependant, nous avons pu réaliser que le serveur rencontrait de gros problèmes dans l’allocation mémoire lors de la réalisation d’un domaine qui contient 25’000 records (sur une table) même si nous avons tunné la JVM comme recommandé par JasperSoft.
Avez-vous aussi identifié ce problème ?
22 juillet 2010 à 7 h 39 min
Bonjour Fred,
Tout d’abord merci pour votre post. Dans ma société nous n’avons pas pousser sur la création de domaine car l’export Excel n’est pas exploitable. Nous n’avons donc pas rencontré ce problème de JVM.
Je vous souhaite bon courage pour votre projet.
A bientôt j’espère!