您有多种选择，各有利弊：
a) 带有闪亮服务器的经典简单闪亮应用
你有什么。正如您所读到的，在 shinyserver 中，闪亮的应用程序在单线程 R 工作线程中运行。这意味着如果您有多个用户，则所有并发用户都将与此 R 工作人员中的应用程序进行交互。如果应用程序有一些缓慢的计算（栅格计算、使用大量数据进行预测、下载大文件......）并且一个用户要求其中任何一项，其他用户将体验到应用程序响应能力下降，因为他们需要等待大计算（他们都不知道）完成。
总之，使用此选项，您会发现您的用户多次点击输入或交互式输出，而应用程序似乎卡住了。 simple_scheduler 在这里对您没有帮助，因为它说明了允许的并发用户数，而不是 R 线程数。
b) 与 shinyserver 异步闪亮的应用程序
Here 你有一个很好的 RStudio 文档，解释了如何使用 promises 和 futures 扩展你闪亮的应用程序。根据您的应用程序的复杂性，实现它的范围可以从“非常容易”到“非常困难”。使用此解决方案会产生更多线程，但仅用于指定计算。但同样，这也有其局限性：
当您的应用程序有一个、两个或几个需要花费大量时间的地方时，异步编程主要是有效的。
如果您的应用更加复杂，并且您必须支持大量并发用户，那么您必须探索不同的选项。
c) 新代理
正如shinyproxy 所说（强调我的）：
ShinyProxy 是您最喜欢在企业环境中部署 Shiny 应用的方式。它具有用于 LDAP 身份验证和授权的内置功能，使保护 Shiny 流量（通过 TLS）变得轻而易举，并且对 Shiny 应用的并发使用没有限制
Shinyproxy 使用 java (Springboot) 为每个访问应用程序的用户启动应用程序的 docker 映像。这导致每个用户一个应用程序，这是您在 shinyserver 中无法做到的。
它的设置比 shinyserver 稍微复杂一些，但可以作为一个选项（事实上，我已经在生产中使用它，而且效果非常好）。
但是，请记住，即使他们声明“... (shinyproxy) 在并发使用方面没有限制”，这也不完全正确。限制是您的服务器支持的。每个应用程序都会消耗 RAM 和 CPU，如果您的应用程序消耗大量内存和 CPU，则用户的限制由您的服务器资源说明，相信我，您不想在生产服务器中触发 OOM 异常（假设一个 linux服务器在这里）。
d) Docker swarm、kubernetes...
假设您可以访问服务器集群，您可以使用 docker swarm 和 kubernetes 等容器化解决方案，因为它们提供了开箱即用的负载平衡（经过一些复杂的配置）。我还不精通这些方法，所以我无法深入了解它们。但最近我正在测试 shinyproxy 和 docker swarm 的组合，以创建一个包含 shinyproxy、Web 服务器和数据库服务器（postgres）的服务堆栈，并且非常有希望。
总结
你需要知道 aprox.您将拥有多少并发用户（约 50 个，您已经完成了此操作）。
您需要非常了解您的应用程序。识别瓶颈和缓慢的步骤。如果可能，请修复/优化它们，并检查应用在单个线程中的响应速度是否足以满足您预期的用户数量。
如果无法优化，请尝试async 并再次检查。
如果这些都没有帮助，您需要深入研究更复杂的解决方案，如前所述。
希望这对您有所帮助。当然，这里肯定还有其他选项没有说明，但我真的不知道他们有什么好评论的；）