déploiement de l'application sur le server shiny de Migale #18
Assignees
Comments
|
Le HOME de l'application dans le serveur shiny sera Le contenu du script de lancement inspiré de la doc de l'appli : |
|
La modification de l'emplacement du dossier Propose de mettre le dossier Il faudra ainsi éditer les lignes de codes concernées pour cette modification |
|
We have the run script and data folder containing the ontologies The dockerfile : |
Revoir globalement les chemins relatifs dans le code qui causent des erreurs. Les modifications vont se faire dans la branche deploy-2-migale-server crée pour le deploiement |
|
Problème de chemins relatifs résolu avec les modifications dans la branche deploy-2-migale-server |
|
L'application apparaît dans la liste des apps
mais l'application met un temps long à charger...
... avant de répondre par une erreur 502
Nous avons cependant au moins pu afficher la page d'accueil en local
|
|
on a modifié
|
|
Application déployée et fonctionne sur l'url https://shiny.migale.inrae.fr/app/ontoRelationVizualizer Une lenteur constatée, elle est apparemment due au démarrage du conteneur docker à chaque nouvelle utilisation de l'application : le conteneur est arrêté après un moment d'inactivé et un nouveau conteneur est crée au lancement de l'appli. |
|
Solutions tentées sans succès pour résoudre le problème de lenteur de lancement de l'app (qui abouti à une erreur 502)
Cela ne résout pas le problème, les logs affichent ceci avec le container qui est activé au bout du 49e essai. avec avec avec avec L'application fonctionne cependant ensuite si on attend un peu et qu'on rafraîchit la page après l'erreur 502 |
|
reprise des tests sur un server shiny dev sur migale. Aucune solution trouvée pour la lenteur de orv Comparaison de temps de lancement entre OntoRelationVisualizer et Easy16S
|
Investigation poussée sur le temps de lancementPour une raison que j'ignore le garbage collector prend beaucoup de temps avant le lancement de orv, le lancement se fait trop tardivement comparé à d'autres outils |
|
Garbage collector plus court avant lancement pour easy16S par exemple |
|
Le cas de MALDIquantTypeR |
|
La lenteur est causée par les instructions dans le global.R ==> il faut trouver un moyen de charger les données après l’affichage de la page d’accueil pour que l’application fonctionne sur le server shiny de Migale test sur un hello world !!! |
|
Les données des ontologies chargées au début de global.R font environ 72 Mo. Et ce, même après les transformations / réductions que nous avions réalisées sur les fichiers bruts (qui étaient autour de 600 Mo). On peut regarder à quel moment il est préférable de les charger mais il faut éviter que cela se fasse au moment où l'utilisateur en a besoin car cela provoquerait de grosses lenteurs (ce que nous avions lors des 1e tests). Je suis dispo pour en discuter si besoin. |
|
Merci @letailli pour la précision. Nous voulons installer sur le ShinyProxy de Migale car cela permet de ne pas avoir de limitation sur le nombre d'utilisateurs travaillant en même temps (chaque utilisateur aura son conteneur indépendant) et cela permet de regrouper les applis shiny au même endroit mais effectivement si on n'a pas de solution pour le temps de chargement on peut essayer de déployer autrement. Je ne connais pas bien R et shiny mais j'ai essayé de regarder le coté traitement asynchrone avec En attendant je vais déployer sur une VM en dehors du shinyproxy. La lenteur au démarrage restera mais au moins on aura l'appli qui tourne. |
|
Merci @mandiayba Je pense qu'il faut éviter de charger ces données pour chaque utilisateur. Cela me semble à la fois lourd pour le serveur et oblige à un temps de chargement pour chaque utilisateur. As-tu plus d'info sur la possibilité de changer une fois les données et les rendre accessibles à toutes les sessions dans l'archi Migale ? |
|
Ce qu'on appelle ShinyProxy c'est un serveur qui accueille des applications
shiny encapsulées dans des images docker. Le proxy surveille en permanence
les applis déployées. Il reste donc en permanence à l'écoute et dés qu'un
user côté navigateur demande une appli (via une URL dédiée) le proxy se
charge de déployer un conteneur dédié à ce user dans le quel tourne une
instance de l'appli demandée. L'utilisateur peut ainsi travailler
tranquillement avec cette instance indépendante.
Si l'instance déployée reste inactive pendant un temps T le proxy se charge
de l’arrêter en supprimant le conteneur. On peut configurer le temps T
mais il s'applique à toutes les applis d'un shinyproxy. Nous l'avons fixé à
moins d'une minute pour éviter qu'il y ait trop d'applis inactives mais on
peut l'adapter si besoin.
Je te donne plus de détails la semaine prochaine.
Le sam. 3 avr. 2021 à 11:40, Charles Letaillieur ***@***.***>
a écrit :
… Merci @mandiayba <https://github.com/mandiayba>
On utilise déjà future à plusieurs endroits. On peut regarder dans ce sens
pour être compliant avec Migale. Pour éviter les lenteurs côté utilisateur,
j'ai besoin de comprendre quand est-ce que le service sera redémarré.
Régulièrement (chaque jour ? Chaque semaine ?) ou bien en fonction du
trafic (il est éteint si il n'y a pas de users)?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#18 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEHRRTS5PII4YHBVVW6OCLTTG3O7BANCNFSM4U4LPWPQ>
.
|
|
Je ne sais pas si c'est possible de configurer le chargement des données
par le proxy mais c'est une idée intéressante que je vais explorer.
Je pensais initialement à ne pas répéter l'étape de chargement si plusieurs
instances tournent en même temps, de mettre une condition qui fait que les
données seront chargées par la première instance et les instances suivantes
en profite. Une condition du genre...
```
if_not_exist(GLOBAL_DATA) GLOBAL_DATA <- load(...)
```
Le sam. 3 avr. 2021 à 11:45, Charles Letaillieur ***@***.***>
a écrit :
… Merci @mandiayba <https://github.com/mandiayba>
Je pense qu'il faut éviter de charger ces données pour chaque utilisateur.
Cela me semble à la fois lourd pour le serveur et oblige à un temps de
chargement pour chaque utilisateur.
As-tu plus d'info sur la possibilité de changer une fois les données et
les rendre accessibles à toutes les sessions dans l'archi Migale ?
On se prévoir un point la semaine prochaine pour en parler.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#18 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEHRRTVDRFAICFABZ4ZACL3TG3PVLANCNFSM4U4LPWPQ>
.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Déploiement de l'application
onto-relation-vizualisationsur le server shiny hébergé par Migale. Une application shiny à déployer sur le server shiny de Migale doit être dans une image docker et avoir un script de lancement selon. Le dockerfile et le script de lancement seront localisés dans le projet des apps shiny https://forgemia.inra.fr/migale/shinyproxy-docker.Étapes
Dockerfile). La recette doit (1) installer les dépendances nécessaires pour l'application, (2) créer un dossier dédié à l'application (/opt/ontoRelationVisualizer) où le code de l'application sera copié, (3) déposer le script de lancement de l'application (run.R) dans le dossier de l'application (4) ajouter une petite doc d'utilisationThe text was updated successfully, but these errors were encountered: