Google Cloud Run 中的意外网络延迟：长期连接与短期连接

Question

我在 Google Cloud Run 中遇到了一种意外行为，该行为严重影响网络延迟，我正在向社区寻求见解。

设置：

• 处理所有流量的单个 Google Cloud Run 实例
• 两种类型的客户端：聊天小部件和 Facebook Messenger webhook

问题：

当处理来自 Facebook Messenger webhook 的消息时，我发现与处理来自聊天小部件的相同消息相比，网络延迟显着增加。唯一的区别在于连接的处理方式：

1. 聊天小部件：

   • 发送 POST 请求
   • 在处理过程中保持连接处于活动状态
   • 通过相同的 TCP/IP 连接接收响应

2. Facebook Messenger Webhook（初步实施）：

   • 接收 webhook POST
   • 立即发送 200 OK，关闭连接
   • 异步处理消息
   • 在单独的请求中向 Facebook Graph API 发送响应

展示延迟差异的日志：

Fbm 日志：

•   DEFAULT 2024-08-16T21:31:50.224488Z fetching qr progress
•   DEFAULT 2024-08-16T21:32:02.287477Z qr progress fetched
•   DEFAULT 2024-08-16T21:32:08.691214Z qr status checked
•   DEFAULT 2024-08-16T21:32:15.787925Z msg queued checked
•   DEFAULT 2024-08-16T21:32:32.488039Z msg processing set
•   DEFAULT 2024-08-16T21:32:32.986875Z new step logged
•   DEFAULT 2024-08-16T21:32:32.987111Z mini thread fetched
•   DEFAULT 2024-08-16T21:32:33.086821Z mini thread logged

小部件日志：

•   DEFAULT 2024-08-16T21:58:42.602917Z fetching qr progress
•   DEFAULT 2024-08-16T21:58:42.675074Z qr progress fetched
•   DEFAULT 2024-08-16T21:58:42.741831Z qr status checked
•   DEFAULT 2024-08-16T21:58:42.808483Z msg queued checked
•   DEFAULT 2024-08-16T21:58:43.027842Z msg processing set
•   DEFAULT 2024-08-16T21:58:43.028527Z new step logged
•   DEFAULT 2024-08-16T21:58:43.028686Z mini thread fetched
•   DEFAULT 2024-08-16T21:58:43.028833Z mini thread logged

分辨率：

通过在消息处理期间保持 Webhook 连接打开，镜像聊天小部件的行为，解决了该问题。

问题：

1. 为什么维持开放的 TCP/IP 连接会显着影响同一 Cloud Run 实例中其他网络操作的性能？
2. Cloud Run 或底层基础设施中的哪些机制可能会导致此行为？
3. Cloud Run 中是否有最佳实践或配置来在不同的连接模式下实现一致的性能？

初步研究： 可能的因素包括连接池、TCP keep-alive 和 Cloud Run 的内部调度，但我无法确定根本原因。

我非常感谢社区对这种行为的任何见解或解释。了解底层机制将有助于优化我们的应用程序，并可能使其他在 Cloud Run 中面临类似问题的人受益。

Answer 1

问题来自于第二个案例中发送到 Facebook Messenger 的即时答复。您可以在这里查看我的其他答案，以了解更多有关原因的详细信息（Cloud Run 设计和定价模型）

---

要解决此问题，您有 2 个选择：

• 设置 CPU 始终开启选项。您将对所有实例的生命周期进行收费，即在收到最新请求后的 15 分钟内，Google 删除实例的超时时间。 -> 如果实例上没有新请求，则会话最多 15 分钟。
• 不要发送 HTTP 响应以保持请求上下文正常。在这种情况下，您可以设置最长 60 分钟的超时。

在这两种情况下，理想的解决方案是能够在后端超时的情况下恢复会话，无论选择哪种解决方案。