我们刚刚迁移到Google Cloud Endpoint v2/java8，发现延迟已经上升。我们经常在跟踪中看到这种请求：
https://servicecontrol.googleapis.com/v1/services/<myapi>.endpoints.<myappid>.cloud.goog:check
这使用大约 14 毫秒。此外，不知何故内存使用量上升，我们的 B2 前端突然开始阻塞并经常出现 10 秒的延迟，这可能是连接池未正确完成的问题，但不知何故之前在端点 v1 和 java7 中不存在。 同时，我们看到每个实例报告 0 个错误(事实并非如此，它一直在大约 10-30 秒后中止请求(，并且我们无法获得任何堆栈跟踪来查看请求像以前一样中止的位置。
终止/重启实例会在一段时间内解决 10s 问题，但这自然不是解决方案。
是否必须执行任何步骤才能实现 v2 承诺的性能改进？
TL;DR - GCE 2.0本身比GCE1.0更快，更可靠，但不要使用API管理，否则你会回馈所有这些收益，然后是一些。
在测试GCE 2.0时，我也看到了严重的缓慢问题，我不可能证明让我的用户遭受如此可怕的延迟下降是合理的，所以我开始确定发生了什么。
这是我的方法论：
我设置了一个最小可行 App Engine 应用，该应用仅包含一个简单的 API 调用，该调用使用终结点 1.0、终结点 2.0 和终结点 2.0 与 API 管理返回服务器时间戳。 您可以在此处查看这些代码的所有代码：https://github.com/ubragg/cloud-endpoints-testing
我将其中每个都部署到单独的 App Engine 应用程序中，并在以下链接中使用 API 资源管理器测试了 API(因此您可以自己尝试(：
GCE 1.0
GCE 2.0
GCE 2.0+AM
结果呢？ 以下是每个 API 上快速连续的一系列请求的结果：
GCE 1.0 GCE 2.0 GCE 2.0+AM
average 434 ms 80 ms 482 ms
median 90 ms 81 ms 527 ms
high 2503 ms 85 ms 723 ms
low 75 ms 73 ms 150 ms
如您所见，没有AM的GCE 2.0既快速又一致。 即使是GCE 1.0通常也非常快，但偶尔会有一些麻烦的异常值。 带有AM的GCE 2.0几乎总是令人无法接受的缓慢，只有在极少数情况下才会下降到"可能可以接受"的范围。
请注意，所有这些时间都是从 API 资源管理器报告的客户端角度开始的。 以下是同一时间段内来自 App Engine 信息中心的相同请求的服务器报告的平均值：
GCE 1.0 GCE 2.0 GCE 2.0+AM
average 24 ms 14 ms 395 ms
因此，最重要的是，如果你关心延迟，API 管理实际上不是一个选择。 如果您对如何在没有 API 管理的情况下运行 GCE 2.0 感到好奇，只需确保不要遵循此处的任何说明：https://cloud.google.com/endpoints/docs/frameworks/python/adding-api-management。
使用没有管理库的基本 API 框架(您提到的 14ms 调用是其中的一部分(，您应该会得到一些改进的延迟。v2 框架中的内存使用量有所增加，因为它现在合并了以前是单独服务的代码。如果您不使用 API 管理，我建议您删除库并查看是否有帮助。它应该消除 14 毫秒的延迟并减少相当数量的内存使用，因为您不会加载那么多代码或数据。