Cloud Run 出口网络高延迟答案

【问题标题】：Cloud Run egress network high latencyCloud Run 出口网络高延迟
【发布时间】：2020-04-05 14:03:48
【问题描述】：

我对 Google Cloud Platform 的 Cloud Endpoint 有疑问。我有一个由 Cloud Function 支持的小型 API，它请求 Cloud SQL 实例中的一些数据。这部分速度很快。

此 API 通过 Cloud Endpoints 和运行的 ESP 代理公开（如 Google Cloud Platform 文档中所述）。

启动时，延迟是合理的（大约 200 毫秒），但有时（没有任何干预）之后，延迟会上升大约 2 秒。然后，如果我强制重新部署 Cloud Run 实例，延迟将恢复正常。

我有另一个端点具有完全相同的配置，但具有由另一个 Cloud SQL 实例支持的云函数，我没有这个问题。

你知道为什么吗？

谢谢！

安东尼

编辑：

低延迟跟踪：

另一个具有高延迟的：

两者都是完全相同的基础架构。重启 Cloud Run ESP 代理可以减少一段时间的延迟（上次是 6 小时，这次是 24 小时没有高延迟）。

【问题讨论】：

您使用的是API management吗？如果是，删除它应该可以解决延迟问题 - 请参阅 this 帖子了解更多信息。您可能会发现此 article 对于减少 Google Cloud Endpoints API 的延迟很有用。
嗨，丹尼斯，感谢您的回复。我不是 Cloud Endpoints 的专家，我认为我并不完全了解流程。我按照tutorial 部署 API 端点（云端点定义和在 Cloud Run 上运行的 ESP 代理）。我用两条带有延迟的跟踪的屏幕截图更新了问题。
您可以通过直接应用logging 并检查您的应用程序上的任何特定延迟来检查您自己的应用程序（云函数）的延迟。您在Endpoint request logs 上看到任何特殊问题吗？ Cloud Functions（相同的代码、相同的运行时）和 Cloud SQL 实例（相同的数据库版本、机器类型、存储容量等）是否相同？
您好，我已经检查了云功能。每次调用只需不到 100 毫秒即可完成。问题来自端点服务/云运行 ESP。我检查了端点请求日志，没有发现任何错误。请求延迟从 259ms 无缘无故地过渡到 2.4s，然后停留在 2s 左右。如果我重新启动云上运行的 ESP 代理，延迟会回到 200 毫秒。
Cloud Run ESP 在哪里创建在不同的区域？

【解决方案1】：

更新：将 ESP 代理更新到 v2 (gcr.io/endpoints-release/endpoints-runtime-serverless:2) 似乎可以解决问题。

【讨论】：

【解决方案2】：

您指的是 CheckServiceControl 延迟吗？

ESP 具有用于 ServiceControl 调用的本地缓存。缓存在 5 分钟后过期。低延迟可能来自缓存命中，而高延迟可能来自缓存未命中。

【讨论】：

我不这么认为，因为我在 6 个位置每分钟都有一个电话，而且我有超过 4 天的低延迟时间。然后延迟在没有任何明显原因的情况下增加并保持高，直到我重新启动 ESP 代理云运行。正如您在两个屏幕截图中看到的，高延迟来自 CheckServiceControl（从 10 毫秒到 1 秒），但也来自云函数调用的延迟（后端从 36 毫秒提高到 1.2 秒，而云函数延迟保持在 30 毫秒左右)
我明白了，您怀疑 Cloud Run 出口网络可能存在延迟问题。一段时间后，延迟会增加，重新启动 Cloud Run 服务将修复它。如果是这样，您能否将此问题提交给 Google Cloud Run 团队？您的问题标题具有误导性，您能否将其更改为 Cloud Run 出口网络高延迟
感谢您的宝贵时间。我编辑了标题，并按照您的建议向云运行团队提出了问题。如果他们发现问题，我会在此通知您。