429 在非常低的 qps 尽管有足够的余量

Question

云中的 Xoogler 在这里。我有一个服务于 HTML 加上后续资源的非常低的 qps 服务。因此，它通常处于空闲状态，然后在 5 秒内收到大约 20 个请求的顺序，并发量远低于 10，其中并发限制为 80。我观察到客户定期从 Cloud 运行收到 429s，通常是在服务不活动期之后，即使实例仍在运行（因此这不是冷启动问题）。这可以在第一个请求中出现，但通常在序列中间的某个位置（即图标，css 不加载）。

该实例是并发的、响应迅速的并且可以轻松处理负载，但云运行不允许。也没有其他实例启动，尽管我们甚至没有达到 2 的最大值。这表明 Cloud 运行出于某种原因估计需要 >2 个实例？

这是一个典型的请求序列，从日志中删除：

... 20 min idle ...
I 2020-03-27T18:21:27.619317Z GET 307 288 B 5 ms
I 2020-03-27T18:21:27.706580Z GET 302 0 B 0 ms
I 2020-03-27T18:21:27.760271Z GET 200 5.83 KiB 5 ms
I 2020-03-27T18:21:27.838066Z GET 200 1.89 KiB 4 ms
I 2020-03-27T18:21:27.882751Z GET 200 1.05 KiB 4 ms
I 2020-03-27T18:21:27.886743Z GET 200 582 B 3 ms
I 2020-03-27T18:21:27.893060Z GET 200 533 B 4 ms
I 2020-03-27T18:21:27.897352Z GET 200 5.35 KiB 4 ms
I 2020-03-27T18:21:27.899086Z GET 200 11.38 KiB 6 ms
I 2020-03-27T18:21:27.905967Z GET 200 22.48 KiB 13 ms
I 2020-03-27T18:21:27.906113Z GET 200 592 B 13 ms
I 2020-03-27T18:21:27.907967Z GET 200 35.08 KiB 14 ms
...500ms...
I 2020-03-27T18:21:28.434846Z GET 200 2.76 MiB 50 ms
I 2020-03-27T18:21:28.465552Z GET 200 2.29 MiB 67 ms <= up to here all resources served from image
...2500ms...
I 2020-03-27T18:21:31.086943Z GET 200 2.95 KiB 706 ms <= IO-bound, talking to backend api
...1600ms...
W 2020-03-27T18:21:32.674973Z GET 429 14 B 0 ms   <= !!!
W 2020-03-27T18:21:32.675864Z GET 429 14 B 0 ms   <= !!!
W 2020-03-27T18:21:32.676292Z GET 429 14 B 0 ms   <= !!!
I 2020-03-27T18:21:32.684265Z GET 200 547 B 6 ms
I 2020-03-27T18:21:32.686695Z GET 200 504 B 9 ms
I 2020-03-27T18:21:32.690580Z GET 200 486 B 12 ms

可以想象最后一组请求是6个并行请求。为什么三个被拒绝而三个被送达？服务能力不足。几次重新加载通常可以解决问题。

在我看来，算法在一段时间不活动后确实大大高估了所需的资源。我很乐意尝试更大的最大实例数（现在重新部署到 10 个），但低端的估计值似乎确实有些不对劲。如果“2”作为并发设置低于平台支持的设置，gcloud 可能应该首先强制执行更高的最小值。

这有点令人难过，因为它只影响 "trying out" 云运行的人，他们观察到间歇性错误（部分呈现的页面，...）- 甚至固定在客户端 (4xx)谁当然没有错。

很高兴提供更多数据。

配置：

template:
    metadata:
...
      annotations:
...
        autoscaling.knative.dev/maxScale: '2'
    spec:
      timeoutSeconds: 900
...
      containerConcurrency: 80
      containers:
...
        resources:
          limits:
            cpu: 1000m
            memory: 244Mi

Answer 1

这看起来像 known issue 云运行，我建议给它加注星标以接收通知并加快解决速度。

429 在非常低的 qps 尽管有足够的余量

429 at very low qps despite adequate headroom

google-cloud-platform

google-cloud-run