ShinyProxy Docker - 最大线程数（最大并发用户数）
ShinyProxy Docker - Max Threads (max concurrent users)
我正在 R Shiny 中创建一个企业范围的表单输入解决方案，该解决方案将面向大约 400 名用户。
我的问题是（简而言之）：由于 R 是单线程进程，我是否需要 200 个内核（假设每个内核两个线程）来支持最多 400 个并发用户？我该如何指定基础架构要求（当前是 32GB 内存，4 CPU）？
如前所述，后端 没有复杂的 R 模型 等，这基本上是一个数据库接口，数据处理最少，所以应用程序非常轻量级，我主要关心的是只是并发用户数。这也是一个本地解决方案。
我正在使用带有 Docker 网桥的容器化版本的 ShinyProxy 与应用程序映像进行通信。
如有任何意见，我们将不胜感激。
如果您想绝对确定给定用户永远不会因为其他人使用 R 进程而遇到延迟，那么是的，您需要为 400 个并发用户提供 400 个线程。
在实践中，如果（如您所说）应用程序没有很多计算密集型功能，那么您可以使用更少的内核。如果一个用户需要 200 毫秒来计算某个函数，那么在任何人注意到一个重要的（例如，1 s) 延迟。如果不涉及大量计算，在用户体验受到负面影响之前，您更有可能摆脱每个线程的数十个并发连接。
综上所述，我对 ShinyProxy 的理解是它会为每个新连接启动一个新实例，因此并发用户数可能会受到内核数的限制。在这一点上我不是很清楚。但是，如果是这样的话，并且假设一个有几百个连接但处理要求很少的模型，我认为更好的方法可能是少数 Shiny Server instances behind a load balancer. The servers would not need to be particularly powerful (you're only using one thread anyway). Each server can handle >100 connections （我不知道是否有上限）。
总而言之，在我看来，当连接较少时，ShinyProxy 会更好 运行 计算密集型应用程序较多，而当您与计算量较小的应用程序连接较多时，Shiny Server（甚至是免费版）会更好应用
在指定基础设施要求方面，一个好的起点是 shinyloadtest。
我正在 R Shiny 中创建一个企业范围的表单输入解决方案，该解决方案将面向大约 400 名用户。
我的问题是（简而言之）：由于 R 是单线程进程，我是否需要 200 个内核（假设每个内核两个线程）来支持最多 400 个并发用户？我该如何指定基础架构要求（当前是 32GB 内存，4 CPU）？
如前所述，后端 没有复杂的 R 模型 等，这基本上是一个数据库接口，数据处理最少，所以应用程序非常轻量级，我主要关心的是只是并发用户数。这也是一个本地解决方案。
我正在使用带有 Docker 网桥的容器化版本的 ShinyProxy 与应用程序映像进行通信。
如有任何意见，我们将不胜感激。
如果您想绝对确定给定用户永远不会因为其他人使用 R 进程而遇到延迟，那么是的，您需要为 400 个并发用户提供 400 个线程。
在实践中，如果（如您所说）应用程序没有很多计算密集型功能，那么您可以使用更少的内核。如果一个用户需要 200 毫秒来计算某个函数，那么在任何人注意到一个重要的（例如，1 s) 延迟。如果不涉及大量计算，在用户体验受到负面影响之前，您更有可能摆脱每个线程的数十个并发连接。
综上所述，我对 ShinyProxy 的理解是它会为每个新连接启动一个新实例，因此并发用户数可能会受到内核数的限制。在这一点上我不是很清楚。但是，如果是这样的话，并且假设一个有几百个连接但处理要求很少的模型，我认为更好的方法可能是少数 Shiny Server instances behind a load balancer. The servers would not need to be particularly powerful (you're only using one thread anyway). Each server can handle >100 connections （我不知道是否有上限）。
总而言之，在我看来，当连接较少时，ShinyProxy 会更好 运行 计算密集型应用程序较多，而当您与计算量较小的应用程序连接较多时，Shiny Server（甚至是免费版）会更好应用
在指定基础设施要求方面，一个好的起点是 shinyloadtest。