我正在 R Shiny 中创建一个企业范围的表单输入解决方案，该解决方案将针对大约 400 个用户。
我的问题是（简而言之）：由于 R 是一个单线程进程，我是否需要 200 个内核（假设每个内核两个线程）来支持最多 400 个并发用户？如何指定基础设施要求（当前是 32GB 内存，4 个 CPU）？
如前所述，后端没有复杂的 R 模型等，这基本上是数据库的接口，数据处理最少，所以应用程序非常轻量级，我主要关心的只是并发用户的数量。这也是一个本地解决方案。
我正在使用带有 Docker 网桥的 ShinyProxy 的容器化版本来与应用程序映像进行通信。
任何意见将不胜感激。
如果您想绝对确定给定用户永远不会因为 R 进程被其他人使用而遇到延迟，那么是的，您需要 400 个线程来处理 400 个并发用户。
在实践中，如果（如您所说）该应用程序没有很多计算密集型功能，那么您可以使用更少的内核来摆脱困境。例如，如果用户计算某个函数需要 200 毫秒，那么在任何人注意到显着（例如，1 秒）延迟之前，您将需要同一线程上的少数用户同时运行此类函数。如果不涉及大量计算，则更有可能在用户体验受到负面影响之前每个线程处理数十个并发连接。
说了这么多，我对 ShinyProxy 的理解是，它会为每个新连接启动一个新实例，因此并发用户的数量可能会受到核心数量的限制。在这一点上我并不完全清楚。但是，如果是这种情况，并且假设模型有数百个连接但处理要求很少，我认为更好的方法可能是负载均衡器后面的几个Shiny Server实例。服务器不需要特别强大（无论如何您只使用一个线程）。每台服务器可以处理>100个连接（我不知道是否有上限）。
总而言之，在我看来，ShinyProxy 在您运行计算密集型应用程序的连接较少时会更好，而当您与计算量不大的应用程序有更多连接时，Shiny Server（甚至是免费版本）会更好。
在指定基础设施要求方面，一个好的起点是shinyloadtest。