haf*_*aff 5 r shiny docker shiny-server shinyproxy
我正在寻找一个免费的开源选项，以便同时向大约 100 名学生提供闪亮的应用程序。我尝试使用 Shiny Server Open 来执行此操作，但它受到限制。用户收到类似这样的消息
Too Many Users
Sorry, but this application has exceeded its quota of concurrent users. Please try again later.
在搜索该错误消息后，我现在知道我可以增加并发连接数，但我担心由于 R 的单线程性而出现瓶颈。我知道 Shiny Proxy 并且一直在尝试这个，但它似乎可能包含我不需要的额外复杂层。
我之前曾使用 Docker 提供过 Shiny 应用程序（但没有面向这么多受众），所以我想知道这是否足够。
我的问题是：如果我不需要身份验证（用户登录），Docker 是否足以支持约 100 个同时连接的单页面应用程序？或者我真的需要闪亮代理吗？
推论：我怎样才能测试它并确保它能够工作（除了在 100 名学生面前进行即时测试之外）？
您关心它们是否都共享相同的底层 R 流程吗？
shiny-server 的开源版本允许您为应用程序提供服务，但它们都共享一个 R 进程。因此，如果您的应用程序有一个长时间运行的模拟，当一个用户运行它时，它会占用您的 R 线程并阻止其他用户，直到它完成运行。
我不知道并发连接是否有限制，如果您不介意它们如上所述共享 R 进程的话。您可以尝试增加设置，请参阅shiny-server.confsimple_scheduler文档中的第3.1.2节简单调度程序（通常位于/etc/shiny-server/）。
如果您不关心它们都位于同一 URL，则可以仅使用开源闪亮服务器的多个实例，例如在计算机上不同端口托管的 docker 容器中。
如果您想在应用程序实例之间进行负载平衡（在单个 URL 后面水平扩展），您将需要闪亮服务器专业版、闪亮代理，或者使用具有粘性会话的负载平衡器。这是因为闪亮的应用程序在 R 会话中处理内存中的状态，因此如果您尝试将学生发送到某个 URL，并且该 URL 由您的应用程序的 n 个实例支持，但没有粘性保证，则比单个学生的操作要好不一定每次都在同一个实例上，并且应用程序不会按您的预期运行。
Shiny-Server pro 和 ShinyProxy 通过 cookie 和标头为您处理这种粘性。根据您的云服务提供商的不同，他们可能支持浏览器 cookie，只要您不需要学生能够使用不同实例打开应用程序的多个选项卡，该浏览器 cookie 就可以工作。