为什么 Cloud Run 的容器数量比应有的数量高出这么多？

Question

我创建了一个新的云运行服务，设置为每秒 50 个最大请求（并发），但在生产中它一直徘徊在最大 2-3 个请求/秒/容器。我知道 cloud run 的目标是将 CPU 保持在 60% 左右，但我已经将其从 1 个 vCPU 增加到 4 个 vCPU，但我仍然没有看到我现在期望的 0.75 req/s 负载所需的 1 个容器。我尝试了“始终分配”CPU，但它并没有减少活动实例数。

到底是怎么回事？有什么办法可以让它坚持我设定的最大值吗？如果继续这样扩展，将会额外花费数百美元，因为我什至还没有打开所有请求。

替代问题：由于成本仅在请求分配期间产生，也许我不需要付费，并且活动容器的数量并不重要？

PS：这是一个无头抓取服务，因此它将运行无头 chrome，这需要大量的 CPU 才能启动，但每个额外的选项卡都不会大幅增加 CPU 要求。

PSS：此外，任何有关保持容器数量较低的建议建议都值得赞赏：我添加了最小活动实例 1，但这就是我考虑的全部内容。

Answer 1

有多个因素可能会影响 Cloud Run 并发性。

• 每个实例（服务）的最大并发请求数

  • Cloud Run 提供每个实例的最大并发请求数设置，该设置指定给定容器实例可以同时处理的最大请求数。

  • 默认情况下每个Cloud Run容器实例最多可以同时接收80个请求；您可以将其增加到最大值 1000。如果需要，您可以降低最大并发数，例如，您的代码无法处理并行请求，请将并发数设置为1。

• CPU分配（服务）

  • 仅 当请求处理期间的 CPU 利用率超过60% 时， Cloud Run 才会进行横向扩展。

  • 如果您选择始终分配 CPU并在没有请求的情况下执行后台活动，则即使 CPU 使用率超过 60% 阈值，Cloud Run 也不会横向扩展，并且在某些情况下，容器实例可能会变得太忙而无法接受传入请求。

• 最大容器实例（服务）数量

  • 由于您已经提到您已将最小实例设置为1，因此最好设置最大实例，以便 Cloud Run 允许您限制服务的扩展以响应传入请求，尽管此最大设置由于流量高峰等情况，可能会在短时间内超出。

这些只是可能影响并发性的一些因素。希望这可以帮助。