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