Avi*_*Avi 11 concurrency r shiny shiny-server
我有一个 R Shiny 应用程序，我想使用开源解决方案托管它以支持大约 50 个并发用户。我遇到了 RStudio 的 Shinyserver，它可用于将闪亮的应用程序部署到网络。我想使用shinyserver的开源版本。
文档说我们可以使用简单的调度程序来定义并发连接数。
Simple Scheduler 是 Shiny Server 开源版本中唯一可用的调度程序。它将单个 R 进程与单个 Shiny 应用程序相关联。此调度程序接受一个参数，该参数指定最大并发会话数。一旦达到此数字，尝试在此应用程序上创建新会话的用户将收到 503 错误页面。
简单调度程序的文档说，
simple_scheduler 一个基本的调度程序，它将为每个应用程序生成一个单线程 R 工作线程。如果未指定调度程序，则这是默认调度程序。
它说开源 Shinyserver 支持单个 R 进程，但同时它提到每个应用程序将有 1 个单线程 R 工作线程。那么如果我想为 1 个应用程序支持 50 个并发用户，我该如何实现呢？我是否需要在同一台服务器上创建应用程序的 50 个实例，还是由 50 个工作线程为应用程序的一个实例提供服务？
另外提到的默认并发连接数是 100。最大是多少？
有人可以解释一下我们该怎么做吗？
Mal*_*udo 16
您有多种选择，各有利弊：
你有什么。正如您所读到的，在 Shinyserver 中，闪亮的应用程序在单线程 R 工作线程中运行。这意味着如果您有多个用户，所有并发用户都将与此 R 工作线程中的应用程序进行交互。如果应用程序有一些缓慢的计算（光栅计算、使用一些大量数据进行预测、下载大文件......）并且一个用户要求其中任何一个，其他用户将体验到应用程序响应速度下降，因为他们需要等待大计算（他们都不知道）完成。
总之，使用此选项，您会发现您的用户多次点击输入或交互式输出，并且应用程序似乎卡住了。在simple_scheduler这里对您没有帮助，因为它说明了允许的并发用户数，而不是 R 线程数。
在这里，您有一个很好的 RStudio 文档，解释了如何使用promises和扩展您闪亮的应用程序futures。根据您的应用程序的复杂性，实现这一点的范围可以从“非常容易”到“非常困难”。使用此解决方案会产生更多线程，但仅限于指定的计算。但同样，这有其局限性：
异步编程主要在您的应用程序有一个、两个或几个花费大量时间的地方时有效。
如果您的应用程序更加复杂，并且您必须支持大量并发用户，那么您必须探索不同的选项。
正如Shinyproxy所说（强调我的）：
ShinyProxy 是您最喜欢的在企业环境中部署 Shiny 应用程序的方式。它具有用于 LDAP 身份验证和授权的内置功能，使保护 Shiny 流量（通过 TLS）变得轻而易举，并且对同时使用 Shiny 应用程序没有限制
Shinyproxy 使用 java (Springboot) 为每个访问应用程序的用户启动应用程序的 docker 镜像。这导致每个用户一个应用程序，这是你在 Shinyserver 中无法做到的。
它的设置比 Shinyserver 稍微复杂一些，但可以作为一种选择（事实上，我已经在生产中使用它并且它运行得非常好）。
但是，请记住，即使他们声明“ ......（shinyproxy）在并发使用方面没有限制”，这也不完全正确。限制是您的服务器支持的内容。每个应用程序都会消耗 RAM 和 CPU，如果您的应用程序消耗大量这些，用户的限制由您的服务器资源规定，相信我，您不想在生产服务器中触发 OOM 异常（假设一个 linux服务器在这里）。
假设您可以访问服务器集群，您可以使用容器化解决方案，如 docker swarm 和 kubernetes，因为它们提供开箱即用的负载平衡（经过一些复杂的配置）。我还不精通这些方法，所以我不能深入了解它们。但是最近我正在测试 Shinyproxy 和 docker swarm 的组合，以创建一个带有 Shinyproxy、Web 服务器和 db 服务器（postgres）的服务堆栈，并且非常有前途。
你需要知道大约。您将拥有多少并发用户（~50，您已经这样做了）。
您需要非常了解您的应用程序。确定瓶颈和缓慢的步骤。如果可能，修复/优化它们，并检查应用程序在单个线程中是否对您预期的用户数量有足够的响应。
如果无法优化，请尝试async并再次检查。如果这些都没有帮助，您需要深入研究更复杂的解决方案，如前所述。
希望这对你有帮助。当然，这里肯定还有其他选项没有说明，但我真的不知道他们愿意评论；）