Cherche retour d'expérience sur shiny, shiny server et web hosting

Version imprimable

22/05/2015, 01h52
bouye

Cherche retour d'expérience sur shiny, shiny server et web hosting

Salut,

je voudrais savoir si certains d'entre vous on déjà utilisé le Framework R Shiny (http://shiny.rstudio.com/) pour développer des web apps en R. S'ils ont utilisé Shiny Server (la version Open Source gratuite ou la version Pro payante) ou le web hosting proposé par https://www.shinyapps.io/ pour distribuer leurs applications soit sur un réseau interne (avec le serveur), soit sur Internet (avec le serveur ou le web hosting) ?

J'ai pu mettre en place hier sans difficulté la version OpenSource de Shiny Server sur une VM tournant sous Ubuntu 14.04 pour créer des tests basiques (ceux du site de Shiny).

Je cherche un retour d’expériences de personnes qui auraient déjà utilisé ce genre de solutions.
Les coûts impliqués, ce qui est performances ou occupations mémoire en fonction de nombre d'utilisateurs connectés, la sécurité, etc.

Au niveau du serveur, est-ce que la version OpenSource est suffisamment robuste et sécurisée en soit ou mieux vaut-il se rabattre sur la version pro histoire d'avoir une once de support technique et plus de features ?

Dans le cas d'une utilisation du service d’hébergement, est-ce que le code de l'application se doit d’être en R uniquement ou est-il possible de spawner des process natifs, etc.
Y a-t-il des limitations au niveau des pages web elles-mêmes qui sont placées sur l’hébergement ou est-ce que n'importe quoi de HTM5+JavaScript (jquery, boostrap, etc.) fonctionne ?

Merci pour tout information que vous pourriez m'apporter.
25/11/2015, 05h04
bouye
Bon vu qu'on a pas mal avancé sur le sujet depuis mai dernier, je vais pouvoir me répondre à moi même, et pointer sur les blogs posts que j'ai créé à ce propos pour que ça soit utile à d'autres :
- Nos scientifiques ont pu sans problème développer de petites applications qui démontraient la faisabilité de la chose et qui peuvent se lancer er local depuis les dernières versions bêta de Rstudio.
- On a pu installer et configurer en interne un serveur R-shiny sur Ubuntu ;
- On a pu egalement installer et configurer un serveur R-shiny sur Raspberry Pi ;
- Pour l’hébergement web on a finalement opté pour un hébergement directement sur shinyapp.io plutôt que de mettre en place notre propre serveur ; on a opté pour la solution a $99 / mois sachant qu'on va probablement descendre à un tarif plus bas d'ici 1~2 mois (ici le but était de rendre une app dispo pour une conf de ~200 personne mais une fois la conf passée, on aura sans doute beaucoup moins de visite. On remontera notre forfait quand on aura plus d'apps en ligne je pense).
L'upload peut directement se faire depuis Rstudio soit via le bouton idoine dans la barre d’icônes soit via une fonction R. Attention cependant : le nom du répertoire de stockage qui contient les fichiers server.R et ui.R sera aussi le nom de l'application sur le cloud ainsi que dans l'URL finale. Éviter donc les noms en haute case ou contenant des espaces ou des _.

L'interface d'amin sur shinyapps permet de monitorer le nombre de connections, la taille de la mémoire utilisée et le temps horaire consommé pour chaque app (utile pour la gestion du quota suivante forfait). En fait, j'ai l'impression que chaque app lance une VM contenant une instance de shinyserver. VM qui sera mise en pause lorsque plus aucune connexion n'est active (par défaut un navigateur se déconnecte d'une app après 15min). De même, la VM est éteinte et relancée lorsqu'on upload une nouvelle version de l'app (de ce fait le packaging + upload peut prendre quelques minutes même pour une app qui ne fait que quelques dizaines de kilo octets de sources R + qq CSS et un ou deux petits PNG pour la deco). Après ça marche bien mais je ne sais pas si c'est lié à R ou à leur serveur (ou les deux) mais ce n'est pas non-plus d'une rapidité d’exécution flagrante.

Un soucis que j'ai noté par rapport à ce que les scientifiques ont produit c'est que R produit des graphes sous forme de bitmaps (via ggplot2) et donc qu'il faut mettre du code dans server.R pour redimensionner le graphe lors que la zone d'affichage dans le navigateur change (si on a opté entre autre pour layout fluide via bootstrap) ce qui implique de le régénérer. De plus, du coup l'image produite est plus grosse lorsqu'on visionne l'app sur un périphérique supportant le hdpi/retina (ici mon iPhone) même si elle donne l'impression de s'afficher en plus petit ce qui engendre un plus long temps d'attente et un plus gros transfert de données. On a pas testé sur des moniteurs capables de faire du 4K mais il est possible que la bitmap produite soit assez énorme en fait ce qui peut poser des soucis de consommation mémoire ou d'allocation de buffer dans R (et puis de temps de transfert sur le réseau). Il doit être possible d’utiliser des graphes HTML/Javascript (démo Google chart) mais on a pas vraiment eut le temps de tester ça sans parler du fait qu'on était pas sur de pouvoir les customiser comme on le voulait.

Quelques petits problème mineurs et non-critiques en cours :
- J'ai noté ici et là que certains contrôles HTML produits par shiny ou des libs R ont leur style codé en dur ce qui rend l'usage d'une CSS externe pénible. Genre il faut coder des fonctions R pour aller bidouiller le contenu HTML produit à grand coup de regexp pour retirer les styles par défaut ou y affecter des classes manquantes.
- Le tag title du header s'affiche correctement sur un test local via Rstudio mais pas sur shinyapps.io
- Même chose pour la favicon de la page.
Donc du coup j'ai cherché à ouvrir des tickets auprès du support mais le compte shinyapp n'est pas reconnu par le support de Rstudio (le bouton aide de shinyapps redirige sur le site de shiny qui envoie sur celui de Rstudio). En attendant, j'ai du laisser un message dans leur groupe Google. J'verrai bien quand ils répondront.

Pour le reste, il faut que je remette au gout du jour mon HTML5/bootstrap...

Et des que je pourrai je vais tester egalement comment connecter Google Analytics sur l'app pour fournir plus de stats que celles de l'interface d'admin du site.
25/11/2015, 16h51
juliatheric

Citation:

Envoyé par bouye

[...] Un soucis que j'ai noté par rapport à ce que les scientifiques ont produit c'est que R produit des graphes sous forme de bitmaps (via ggplot2) et donc qu'il faut mettre du code dans server.R pour redimensionner le graphe lors que la zone d'affichage dans le navigateur change. [...]

Bonjour et merci de ce retour,
Les graphiques produits avec ggplot2 peuvent être sauvegardés dans plusieurs formats. Si, par exemple, vous optez pour le SVG, il n'y aura aucun besoin de rasteriser le rendu, par conception les SVG sont redimensionnables sans perte de la qualité du rendu. Une fois un graphique généré (appelons x la variable qui le contient), on le sauvegardera ainsi :

Code:

ggsave(plot = x, filename = "un_graphique.svg")

Les arguments de ggsave sont décrits dans la doc :

Code:

help("ggsave", package = "ggplot2")
26/11/2015, 01h41
bouye
Merci mais le problème si j'ai bien compris (garde a l'esprit je suis un dev spe Java, que R est l’apanage des scientifiques et que Shiny est nouveau pour nous tous) n'est pas tout a fait identique. Ici on ne fait pas explicitement la sauvegarde du graphe en invoquant ggsave() ; c'est Shiny qui s'en charge... probablement.

Par exemple, dans ui.R :
Code:

1 2 3 4 5 6 7 8 library(shiny) shinyUI( fluidPage( titlePanel("Test Charts"), plotOutput('plotChart', width="100%", height = "475px") ) )
Ce qui invoquera la fonction plotChart dans server.R :
Code:

1 2 3 4 5 6 7 8 library(shiny) shinyServer(function(input, output) { output$plotChart <- renderPlot({ [...] hist([...]) }) }
Il semble qu'ensuite renderPlot() invoque une autre fonction de Shiny qui est renderPNG(). L'image est ensuite injectée dans le tag <img> de la page. La doc indique cependant qu'il est possible de fournir du contenu qui soit perceptibles d’être injecté dans un [c]<div>[c/] a la place ce qui permettrait d'utiliser des libs HTML5 plutôt que des graphes bitmaps. En tout cas, a ce niveau, output est censé contenir du HTML donc en fait il est possible d'injecter tout et n'importe quoi (en théorie).

Après on peut faire comme dans l'exemple du binding sur Google Chart et utiliser d'autres fonctions customs pour déclarer la GUI au lieu de plotOutput(). J'ai un peu testé avec Google Chart mais je ne suis pas fan du résultat, entre autre on ne peut pas vraiment spécifier le nombre de bins pour un histogramme c'est la lib qui choisit automatiquement.

Apparemment il est possible de bidouiller pour utiliser des lib, tierces : Interactive Visualizations with rCharts and Shiny, mais le code donné ici semble être pour une version plus ancienne de Shiny et la lib semble avoir des soucis au niveau de sa licence d'utilisation.

Bonjour,
renderPlot et similaires ne sont pas utiles au rendu du SVG qui, par conception, n'est que du texte. Dans l'application, il suffira donc d'afficher du texte.

ui.R

Code:

1
2
3
4
5
6
7
8
9
shinyUI(fluidPage(
    titlePanel(title = "Vérifier Si On Peut Charger Un SVG"),
 
    mainPanel(fluidRow(
        div(id = "zoneRendu",
            htmlOutput("renduSVG")
        )
    ))
))

server.R

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
shinyServer(function(input, output) {
    invisible(sapply(c("ggplot2", "shiny"), library, character.only = TRUE))
 
    output$renduSVG <- renderText({
        graphique <- ggplot(data = iris, aes(x = Sepal.Length, y = Sepal.Width)) +
            geom_point() +
            theme_light()
 
        ggsave(plot = graphique, filename = "graphique.svg", width = 6, height = 4)
 
        readLines("graphique.svg")
    })
})

19/09/2016, 10h32
Alexandre13

Bonjour,

En premier lieu, je tiens à vous remercier pour ce retour d'expérience, les posts sur Shiny server sont rares!

Ensuite, étant nouveau sur ce site, je vais rapidement me présenter et vous dire ce que nous sommes en train de faire : je suis statisticien au sein de l'ITSAP - Institut de l'abeille. Nous sommes en train de réaliser un projet ciblant la création d'une base de données (MySQL), sur lesquelles des interfaces de visualisation des données se reposeront (il y en aura plusieurs dédiées à des types de données très différents : structure des colonies, analyses chimiques, sélection, etc.). Étant (très) débrouillard sur R et curieux de l'informatique, je me suis donc lancé sur Shiny et ce que j'ai réussi à produire nous convient très bien en terme de rendu. Cependant, la question se pose de l'articulation avec la base de données, développée par des informaticiens avec qui je travaille et qui n'ont pas connaissance du fonctionnement de Shiny.

En clair, ce que nous voulons créer est un portail web qui intègre :
1 - Les outils d'administration de la base de données et de la gestion des données (saisie / extraction)
2 - Les interfaces de visualisation des données, qui permettront de travailler directement ce que l'utilisateur aura constituer comme jeu de données à partir du menu "extraction".

Le 1 sera développé en pHp par les informaticiens, le 2 en Shiny, essentiellement par moi.

La question que nous nous posons est : est-il possible d'intégrer des applications Shiny dans un portail développé en pHp (je crois...)? Si oui, comment?

Avez-vous fait qqch de similaire? Toute piste nous intéresse.

Pour l'heure, nous avons vu que Shiny retournait du HTML, et l'idée énoncée par les informaticiens revient à l'installer dans une VM qui échangerait avec une autre (située sur le même serveur physique) dont le rôle est de gérer la base de données ainsi que le portail web global. Shiny ne serait donc utilisé que pour retourner du HTML, repris dans le portail. L'intérêt est que l'authentification et les droits seront gérés par l'infrastructure de la base, ce qui implique que la version gratuite de Shiny server nous suffirait. Cependant, sur toutes les docs que j'ai consulté, ce type de montage n'était pas évoqué. Il ne s'agit toujours que de la gestion de Shiny, et non de son intégration avec autre chose.

Je n'ai pas les connaissances en informatiques de mes collègues, alors tout ça a un côté "boite noire" pour moi! Cependant, n'ayez pas peur d'entrer dans les aspects techniques, je ferai suivre aux collègues plus compétents que moi dans ce domaine.

Merci d'avance pour toute suggestion.

Cordialement.

Edit : qq posts de forum à côté desquels j'étais passé, et qui apporte des pistes :
http://stackoverflow.com/questions/1...nt-application

"You could use Shiny Server as a proxy behind Apache or Nginx. In other words, you might have hhttp://your_application/shinyapp/ be proxied to your Shiny Server but have all other URLs served up another way."

et https://groups.google.com/forum/?fro...ss/2VwEWXYJwYs

où on peut lire :

You can use an iframe -- that's actually what's done on the main RStudio Shiny page: http://www.rstudio.com/shiny/

The code there is something like this:
<iframe src="http://glimmer.rstudio.com/rstudio/faithful/" style="border: none; width: 440px; height: 500px"></iframe>
18/07/2017, 19h22
florent35

Bonjour Alexandre13,

Je suis aujourd'hui dans une situation très proche de la tienne lorsque tu as posté ton message il y a presque un an. C'est à dire que j'ai une application web (javascript, vb.net) qui se connecte à une base de données ORACLE et qui permet de requêter et d'analyser les données. J'aimerais incorporer dans cette appli une partie Shiny et je pensais, moi aussi, pour cela installer Shiny server sur une VM sur le même réseau que ma base de données et mon application web et intégrer la shiny app via une iframe.
Tout comme toi je suis statisticien et non informaticien du coup je vois grosso modo comment cela peut fonctionner mais en détail c'est très obscur ! comment se connecte l'application shiny à la base de données ? comment passer des paramètres entre l'application web (le portail php) et l'application shiny (le nom de l'utilisateur connecté par exemple) ? comment démarrer et arrêter l'application shiny ou doit-elle être toujours lancée ?

Comme je pense que ce sont des questions que d'autres peuvent se poser est-ce que tu accepterais de nous faire un retour d'expérience sur ton projet ?

Merci d'avance,

Cordialement
19/07/2017, 03h14
bouye
Citation:

Envoyé par florent35

Tout comme toi je suis statisticien et non informaticien

Moi c'est l'inverse :P
Je vais donner un bref retour même si je pense que c'est le sien qui serait plus intéressant. Bon, l’ennui c'est qu'on a pas poussé plus loin dans cette direction depuis cette première tentative (fin 2015). Y avait de l'idée mais peu de temps/de manpower ou de volonté de la part des scientifiques pour réellement rendre le projet concret au-delà d'une simple application de test/démonstration. Donc je ne peux pas t'en dire plus que ce qui va suivre :

Nous avions pour but de déployer une toute petite application de demo pour la réunion de la Commission Thonière du Pacifique Occidental et Central à Bali fin novembre 2015. L'application ne serait utilisée que ponctuellement, quelques minutes seulement (vu le peu de fonctionnalités) lors de sa présentation et par une audience très ciblée/limitée (dont le nombre devait s’étaler de 0 aux 300+ personnes présentes avec probablement une moyenne a 60 personnes - bref une pichenette par rapport a ce que tu cherches a faire je pense). Vu le peu de temps imparti pour le développement et les tests préliminaires, cette application ne contient pas grand chose ; a l'origine il devait y avoir une DB embarquée Access mais les fonctionnalités ayant été grandement revues à la baisse, ça a été éliminé et l'application finale est très minimaliste et se contente de faire quelques calculs et d'afficher des graphes.

Nonobstant, nous avons réfléchi a divers moyens de déployer l'application pour la rendre accessible aux participants sachant qu'on avait aucun contrôle sur la manière dont les accès réseau et WiFi sur le site de la conférence car tout était pris en charge directement par l'équipe technique de la Commission. On a envisagé plusieurs choses :
- Expédier sur place un PI "prêt a l'emploi" avec Shiny-server et l'app pour servir de serveur local (d'ou mon blog-post de l'époque) mais on a retoqué cette solution car on avait peur que le PI ne puisse tenir la charge des utilisateurs.
- Expédier sur place une VM ou un PC avec Shiny-server et l'app pour servir de serveur local. Malheureusement l'équipe technique de la Commission nous a indiqué qu'il ne pourraient pas s'en charger (ce qui serait aussi arrive si on avait envoye un PI de toute manière).
- Ajouter un hébergement sur notre propre serveur web mais plusieurs points (qualité de la connexion vers la NC, notre propre service informatique qui veut tout délocaliser et faire que ça soit des services/boites externes tiers qui se chargent de ce genre de chose, et le fait qu'on était pas vraiment sur que la technologie -qu'on venait a peine de tester- soit assez stable et secure) ont fait qu'on a très vite abandonné cette solution.
- Utiliser l’hébergement shiny.io (d'ou ce topic) ne sachant pas trop si Rstudio disposait d'assez de bande passante ou de miroirs pour rendre leur hébergement efficace.
- Utiliser un hébergement Cloud externe (mais nous manquons d’expérience en ce domaine... même encore aujourd'hui d'ailleurs).
Par manque de temps nous avons finalement opté pour shiny.io, et avons rapidement modifier l'application pour la rendre compatible avec l’hébergement web et modifie l'application fournie par les scientifiques pour lui rendre un aspect plus abordable (LnF requis, mentions légales, passage sous Git, etc.). Nous avons opté pour le starter plan étant donné les contraintes et les limites de l'application. L'ennui c'est que l’accès WiFi a Bali s'est révélé être extrêmement mauvais avec une bande passante assez faible et donc que finalement au maximum on a eut 22 utilisateurs qui ont pu se connecter (très difficilement d’après les retours des gens sur place). Elle a été plus tard présentée a nouveau lors d'ateliers d'avril a juillet 2016 ou il y a eut des pics de jusqu’à 30 personnes de connectées.

La plupart des plans ultérieurs que nous avions pour développer plus d'application sur Shiny n'ont pas porté leurs fruits. Ici, en interne, avec le service technique, nous avons préparé début 2016 un espace de développement test pour que les scientifiques puissent faire joujou dans un "bac a sable" pour développer des apps destinées soit a du training soit a des présentations lors des futures réunions de la commission ou de son Comité Scientifique mais rien ne s'est concrétisé et plus personne ne développe en Shiny depuis mi-2016. Nous avons fini par repasser l’hébergement sur shiny.io en free pour éviter de payer pour rien bien sur.

Donc voila je ne sais pas trop comment cela peut aider tes problématiques. Pour ce que j'en sais de base, et c'est clairement indiqué sur le site https://www.shinyapps.io/ quand tu vas voir le pricing, c'est qu'ils comptent surtout le nombre d'heures actives. Donc plus tu auras d'utilisateurs plus ce nombre montera vite. Quand elle est hébergée sur leur site, une app Shiny est automatiquement mise en pause (elle devient grise et inutilisable) au bout de quelques instant quand l'utilisateur n'est pas actif dessus et ce pour éviter que toi le client tu ne gaspilles ton quota. Lorsque tu utilises ton propre serveur, l'application est tout le temps active par contre du coup ici la variable limitante va etre le nombre de connexion simultanée acceptée par le serveur (20 max sur Shiny Server Pro d’après ce blog post de juin 2016). Hum rien qu'en écrivant ca je me rends compte que leur scalability est quand même plutôt faible en fait (difficile de faire du tres large volume d'utilisateur vu que le large user pack mentionné n'est que de 150)... Pour le reste : plusieurs centaines/milliers/dizaines de milliers ou plus de personnes ? Des sessions avec passages de paramètres ? Connexion permanente a une DB cloud externe ? Je ne sais pas car on a pas été jusque la (et ce n'est pas -encore mais ça le deviendra peut-être- notre fond de métier habituel). Bon évidement si tu passes utilisateurs payant tu auras sans doute plus de facilite pour leur demander de l'aide sur ces sujets directement (s'il ont corrige les problèmes du support que je mentionnais plus haut a l’époque).
19/07/2017, 10h01
Alexandre13

Bonjour,

Ok pour vous faire un point de notre état d'avancement.

En premier lieu, nous sommes encore en cours de développement. La base de données est terminée en ce qui concerne son modèle, mais pas encore en production (le développement de l'interface avance bien mais il reste du boulot). Côté applications shiny, j'ai bien progressé et je suis assez fier du résultat, notamment sur l'une d'entre elles qui comprend un outil carto permettant de faire des requêtes pour connaître l'occupation du sol sur une aire de butinage. Bref, on peut vraiment faire des trucs très chouettes et les développeurs avec qui je travaille ont été assez surpris du résultat. J'ai pu tester l'intégration de 2 applications dans un site web via les iframe. Ça se fait bien, sans connaissances particulières j'y suis arrivé assez rapidement. Petit retour là-dessus, en restant sur des offres gratuites, fuyez wordpress qui impose un compte payant pour récupérer le plugin iframe. Sur Drupal en revanche, pas de problème. Néanmoins, je ne suis pas hyper-convaincu de l'ergonomie de l'ensemble et j'en viens à reconsidérer de réunir les applications directement dans Shiny, ce qui a des avantages (en gros, chaque appli s'intéresse à un type de données particulier, donc en les réunissant ça permet de faire une seule fois la sélection des colonies, puis de regarder telle ou telle chose) et des inconvénients (taille du code, mémoire requise par utilisateur, réunion des utilisateurs sur une même appli au lieu de les ventiler sur plusieurs...). De même avec le fait d'utiliser un site web intégrant les applis, il est beaucoup plus commode de faire l'animation (actualités du projet, tutoriels vidéos, etc.), mais un peu moins pratique d'utiliser les applis (ce serait chouette de pouvoir passer l'iframe en plein écran, comme une vidéo...). Je dois encore réfléchir au meilleur compromis...

Un retour sur les aspects techniques maintenant :
- On a décidé de séparer franchement interface de gestion de la base de données et applications de visualisation des données (shiny donc...), ce ne sera donc pas sur un même site avec navigation par menu etc. Plusieurs raisons à cela, déjà c'est plus clair pour nous, on se réparti mieux les tâches et l'intérêt côté ergonomie n'est pas clairement établi. A terme on reviendra peut être là-dessus, mais pour l'heure on en reste là.

- On est en train de prendre une VM sur laquelle sera hébergée la base de données, son interface de gestion, et Shiny server (version gratuite). On sera sur Centos 7, et il y a des tutos clairs pour l'installation.

- Il n'y a aucune raison que la connexion à une base de données depuis les applis Shiny pose problème. Vous l'avez compris, on n'en est pas encore là, mais toutes mes recherches aboutissent à la même conclusion, ça n'a rien à voir avec Shiny en fait. R peut très bien se connecter à une base de données (le package dépend du type de base, en vrac RMySQL, Rodbc, Rodb, etc.) et il suffit d'intégrer cela dans l'appli pour faire appel aux bonnes requêtes (ou bien les construire à la volée en fonction de selectInput, par exemple). La seule question en suspend est comment gérer les droits d'accès en restant sur shinyserver gratuit. À ce propos, je citais une phrase que je n'avais pas encore les moyens de comprendre à l'époque concernant l'utilisation de nginx. Voilà un site qui m'a permis d'y voir plus clair : https://auth0.com/blog/adding-authen...-shiny-server/
Ça l'air vraiment prometteur, et ce service auth0 est gratuit jusqu'à 7000 utilisateurs (d'ailleurs, ils n'évoquent pas la limite indiquée par bouye, mais j'y reviendrai). Bref, le jour où j'atteins ce nombre, je sabre le champagne! Je pense qu'on doit pouvoir récupérer l'utilisateur suite à cette authentification, mais je ne sais pas encore comment... Une autre piste via apache est mentionnée ici : https://www.r-bloggers.com/password-protect-shiny-apps/ , et un autre post sur ce blog traite de l'hébergement sur AWS et sécurisation SSL : https://www.r-bloggers.com/shiny-htt...urce-with-ssl/ .

Pour ce qui est de la communication entre une interface php et une appli shiny, je ne sais pas trop... A froid, je dirais que les infos que tu veux passer depuis Shiny vers le portail php peuvent être écrite dans un dossier sur ton serveur (fichier text, csv, etc.) puis être repris par ta page web. Ce n'est pas forcément très élégant (crado est mon 2e prénom :P), mais ça doit faire le taf... Je ne dis pas qu'il n'y a pas de meilleur solution. En revanche, ceci est bien sûr impossible si tu passe par shinyapps.io, déjà car ton ton appli n'est pas située sur le même serveur que ton portail, mais aussi car elle change de serveur physique d'un coup sur l'autre (je crois avoir lu ça dans la doc au sujet du stockage de données à long terme dans les applis, je trouvais que c'était intéressant à relayer ici). S'il s'agit simplement du nom d'utilisateur, peut être que placer l'authentification avant d'arriver sur ton portail résoudra la question. Un développeur devrait pouvoir répondre mieux que moi là-dessus.

Ta dernière question concerne l'administration de shiny server, et je n'ai pas encore touché à ça. Je vous ferai un retour quand j'aurais défriché cette zone là.

Je reviens maintenant sur ce que Bouye nous dit concernant la scalabilité. Je suis sidéré d'apprendre cela et j'ai encore du mal à y croire... Faire payer 10000 € / an pour moins de 150 utilisateurs simultanés me semble être un gros foutage de gueule! Déjà, ne pas mettre l'authentification dans une version gratuite (ou même payante mais pas trop) c'est limite, mais là! En poussant un peu la lecture via le lien fourni en bas de la page que tu nous as donné (https://support.rstudio.com/hc/en-us/articles/220546267), je me rends compte que ce n'est pas tout à fait exact. En fait, les 2 pages me semble se contredire... En gros, ils disent qu'il y a 3 paramètres :

1 - le nombre max d'utilisateurs simultanés dont la valeur par défaut est 20. Au delà, un nouveau process R est lancé. Cette variable peut être ajusté et ils ne disent pas que la valeur est limitée. Ils parlent ici de connexions mais le schéma pointe des browser différents. Je précise cela car il semble y avoir confusion entre "utilisateurs concurrents" et "connexions" par rapport à la page que tu nous as fourni...
2 - Le "loadFactor" qui semble conditionner la propension du shinyserver à lancer de nouveau process (là encore c'est un peu flou comme notion...).
3 - Le nombre max de process lancé par shiny server, valeur par défaut de 3, pas de limite indiquée.

Du coup, par défaut on peut aller jusqu'à 3*20 utilisateurs, 3*150 en payant j'imagine... J'avais déjà vu cette page, et vu qu'aucune limité n'est donnée, je pensais qu'il s'agissait simplement de paramétrage pour s'assurer que les sessions R ne surcharge pas en mémoire, et éventuellement de ne pas dépasser la capacité de la VM... Je trouve que ce n'est vraiment pas clair, et très explosif. De mon côté, j'ai peu d'utilisateurs sur le projet en cours, et donc ça ne me gène pas outre-mesure, mais j'avais en tête un projet ciblant un public bien plus large et ça devient casse-gueule si cette question n'est pas résolue! Je vous ferai un retour là dessus également si j'en apprends plus, n'hésitez pas à faire de même parce que là...

Je terminerai sur ce point en disant que sur shinyapps.io, une appli trop gourmande peut crasher quand trop d'utilisateurs sont connectés. Apparemment, il faut allouer plus de mémoire à chaque instance (par défaut, on a 1GB) ce qui demande un compte payant...

En espérant que ce retour vous aura été utile. N'hésitez pas à relancer de manière plus spécifique, je répondrai de manière plus concise (promis!).
Bonne journée à tous.
19/07/2017, 12h56
bouye

Pour ce qu'on en avait vu lorsqu'on avait testé sur le PI à l'époque, on avait 1 instance de R lancée par connexion utilisateur. Donc avec 2 user connectés depuis 2 machines/navigateurs différents on avait 3 R qui tournaient sur le PI : celui du serveur et 1 pour chaque utilisateur. Ce qui commençait à mettre déjà un peu à mal la mémoire du PI (un B de 1ere génération). On avait pas trop tenté de voir comment on pouvait gérer la scalabilité avec nos tests sous CentOS ou en allant bidouiller les options du serveur. Vu qu'on manquait de temps (pour faire des tests supplémentaires et potentiellement mettre ça sur une VM sur le Cloud après) et vu le peu de coopération de notre propre service technique, on avait du choisir l'hébergement sur shinyapp.io assez rapidement.
20/07/2017, 12h24
florent35

Bonjour,

Merci à tous les deux pour vos réponses ;)

J'y vois désormais un peu plus clair. L'application shiny doit effectivement pouvoir se connecter à la base de données via Rodbc comme je le fais déjà avec R classique. Je n'aurais pas d'identification à gérer sur l'application shiny car cette dernière sera accessible via une iframe dans un site web sur lequel l'utilisateur se sera préalablement authentifié, il me faudra simplement réussir à passer les informations de connexion du site web à l'application shiny. Ce point reste en suspend mais de ce que j'ai pu voir sur internet cela semble possible. Pour la communication dans le sens inverse (application shiny vers site web) c'est effectivement plus simple on peut passer par des fichiers sur le server ou stocker les paramètres en base de données. J'espère qu'appeler l'application shiny dans un iframe ne posera pas de problème de sécurité et ne sera pas bloqué, IE, cross-domain ?

Vu les tarifs nous allons partir sur shiny server open source. Vos derniers messages m'ont fait un peu peur sur le nombre limite d'utilisateurs ! Après quelques recherches sur internet je pense que l'on ne comprend pas bien ce qu'ils veulent dire, mais c'est tellement peu clair..... Naïvement je me dis qu'une telle solution ne peut pas être contrainte à 150 utilisateur max pour plus de 10k€/an, le prix cible des clients qui veulent diffuser large et 150 c'est trop peu, ne serait-ce que sur le site de shiny il doivent s'attendre à plus de 150 connexions simultanées !
De ce que j'en comprend notamment au regard de cette page https://support.rstudio.com/hc/en-us...iny-Server-Pro :
- Avec shiny server open source c'est une application shiny = 1 process R (ce qui m'étonne c'est que c'est contradictoire avec ce que tu dis Bouye). Ce qui veut dire que si 2 utilisateurs se connectent en même temps ça va être chacun leur tour, imaginons un modèle qui tourne en 30 secondes le premier a ses résultats en 30 sec le deuxième attends 1 min (30 sec + 30 sec). Si 2 utilisateurs se connectent à 2 applications différentes alors comme chaque appli à son process c'est simultané (à condition que le serveur est au moins 2 processeurs). Cette page semble confirmer cela https://www.r-bloggers.com/shiny-ser...pu-bound-apps/ en proposant l'idée de déployer plusieurs fois la même application et de gérer ensuite la redirection vers l'application la moins utilisée.
- Avec shiny server pro c'est plus compliqué, une application peut utiliser plusieurs process. Je pense que 20 concurrent users veut dire jusqu'à 20 process pour une même application shiny (pas certains de cela). Cependant selon l'application il n'est pas évident qu'il soit toujours préférable que 2 utilisateurs souhaitant accéder à la même application est chacun leur processus car dans une application shiny il y a des parties qui peuvent être partagées entre les utilisateurs ainsi 2 utilisateurs sur le même process ça peut éviter certains chargement, computation et limiter l'usage de ram (pour l'instant je ne me suis pas intéressé à l'écriture des applications shiny donc cela n'est pas très clair pour moi). En tous cas cela est gérable avec shiny server pro via les 3 paramétrages indiqués dans le message précédent d'Alexandre (ses points 1, 2 et 3).

Bonne journée à tous
20/07/2017, 15h19
Alexandre13

Re,

Je pense qu'ils différencient vraiment "utilisateurs concurrents" de "process R". Le hic est que comme R est un langage séquentiel, effectivement les temps de calcul se cumulent pour les utilisateurs d'une même session, logiquement. Peut être que cela doit nous inciter à paralléliser les calculs les plus gourmands, ce qui est possible (https://blog.snap.uaf.edu/2013/07/18...ve-expression/) mais soulève d'autres questions (nombre de nœuds disponibles...).

Sans être spécialiste de la question, je ne vois pas pourquoi un iframe poserai des problèmes de sécurité. Quand à ceux qui utilisent IE :aie:

Bon, ça sent le sapin niveau sur le nombre d'utilisateurs... Donc Shiny serait (je reste au conditionnel quand même...) plutôt pour des appli à public limité, genre petit projet pour une équipe scientifique quoi... Ça reste étonnant je trouve, et c'est surtout une info qu'il faut déterrer...

Bon courage pour la suite de vos projets.
A+
21/07/2017, 17h47
Alexandre13

Bonjour,

Bonnes nouvelles, apparemment on peut passer outre les limitations imposées par Shinyserver open source. L'idée est de dupliquer l'appli que l'on souhaite mettre à disposition et de rediriger les utilisateurs vers celle qui est le moins chargée. De fait, on se retrouve donc avec plusieurs sessions qui travaillent en parallèle donc (comme dans la version pro)... J'ai trouvé 2 liens allant dans ce sens, l'un propose de faire ça avec une autre appli Shiny (l'utilisateur choisi sa session), l'autre le fait par un bash pour que ça reste transparent pour l'utilisateur :

via shiny : http://jaehyeon-kim.github.io/2016/0...Balancing.html
via un bash : http://withr.me/shiny-app-for-cpu-bound-task/

Ça semble régler le problème...

@ Bouye : j'apprécierai vraiment d'avoir ton avis au moins sur le deuxième (le post est plutôt court) car tu es bien plus à même que nous de juger de la pertinence de ce qui est proposé... Moi, sorti de R, j'entrave pas grand-chose :oops: En espérant que tu auras le temps. Merci d'avance.

A+