---
# System prepended metadata

title: Performances Eno
tags: [Bowie]

---

---

robots: noindex, nofollow

---


# Performances Eno

## Symptômes

### INTEGRATION : Questionnaires muti-modèles et génération questionnaire
Enquête ESA --> 20min de génération, timeout swagger à 11min.

### VISUALISATION POGUES : Questionnaire complexe
FPG "Ici, problème de visualisation récurrent sur le questionnaire enquêtes  déchets services kfp3p6nk compte EXN6BE (53 pages de specs tout de même que je joins en pj, 7 redirections et 56 contrôles)."

Lien : https://conception-questionnaires.insee.fr/#/questionnaire/kfp3p6nk
IDEP : EXN6BE


> --> comment est-utilisé la visualisation ?
> Besoin de visualisation de tout le questionnaire : quand, pourquoi ? 
"Limiter les actions qui coûtent cher."
Faire un "résumé" du questionnaire
Profondeur dans xforms

**Les pratiques sont variés parmi les concepteurs : mais la visualisation est nécessaire à tout moment, notamment pour vérifier filtre et contrôles.**


## Pistes 
1 - Montée de version les bibliothèques utilisés
**Montée de version Saxon vers la 9.9.1-8 (v d'oct. 2020) bénéfique ! --> Bonne piste ", la montée de version de Saxon 9.7.0-8 à 9.9.1-8 semble bien régler le pb de perf observé sur le questionnaire déchets en ddi2lunatic-json"**

Marche avec Java 11 : les tests passent bien (saxion 10 : les tests ne passent plus... pb qui concerne plutôt le xslt fonction un truc vide)

2 - Configuration serveurs --> test en local (visual VM --> diagnostic performance côté Java) **non fait au 25/05**
---> test + questionnaires x10
3 - Dégradation des perf linéaire ou pas ? **non fait au 25/05**
ESA : 48 questionnaires à générer --> conception différente : batch ? 
4 - XSLT : améliorations contrôles ! 
Qu'est-ce qui côute cher dans la génération Eno ?
5 - Moteur de transformation XSLT plus performants  ?

## Plan d'action
1 - Montée de version des bibliothèques
**Ok en recette le 20/05/21**
1bis - demande conf serveur (1 ou 2 CPU) RAM ??
**en prod : 2CPU et 2Go de RAM, en DV et QF : 1 CPU et 2 GoRAM**  (http://hyperx.shiny.insee.fr/)
1ter - identification des améliorations XSLT
2 - Diagnostic de "où ça vient" (appui STAC) Visual VM **non fait au 25/05**
3 - Benjamin WS/batch - SST ? **consultation DAAP**
4 : 
--> Piste "tout java" POC Fabrice : comparaison ? 
--> Retour du POC avant : https://gitlab.insee.fr/sndi-lille/stac/travaux/poc-eno-java
**Récupération du POC pour la transfo ddi2poguesxml**
5 : Redéfinir le besoin pour la visualisation : **non a priori**

Test : Pogues logement 

---
Montée en 3.0 XSLT --> compatibilité ascendante assurée.  
Ajout de fonction evaluate intéressante (supporté par le moteur jusque là mais pas la spec XSLT). (preuve de dépôt).
Jusqu'en 2010 : 1 seule version
Dans Orbeon : version payante pour une fonction qui n'est pas dans la version open source.


-----
appel d'API asynchrone 
discussion dans le cadre de Métallica 
Batch API qui sont de manière asynchrone et une architecture basé sur les commandes d'évènement.

exucution de traitement asynchrone sur des serveurs web (broker)

2 US : 
- génération de questionnaire dans le cadre de l'intégration de questionnaire (appel swagger des web-service aujourd'hui, automatisé ou via d'autres outils prochainement)
--> retour immédiat "traitement en cours" et retour du résultat quand il arrive et WS "état de la demande"
voir côté Sirene 4 "quelque chose comme ça" (déclaration d'entreprise : simple donc validation facile mais cas plus complexe, traitement et vérif et réponse plus tard)
gestion évènementiel "event store", architecture de pattern "event sourcing"
architecture orienté évènement
stockage de la réalisation dans une base évenement : répertoire temporaire (réponse du dinosaure) ?
garder le stateless le plus possible
persistence des évenmenets à part si besoin (garder le stateless)
- visualisation Pogues


