3

我们刚刚迁移到 google cloud endpoints v2 / java8，发现延迟上升了。我们经常在 trace 中看到这种请求：

https://servicecontrol.googleapis.com/v1/services/<myapi>.endpoints.<myappid>.cloud.goog:check

使用大约 14 毫秒。此外，不知何故，内存使用量上升，我们的 B2 前端突然开始阻塞并经常延迟 10 秒，这可能是连接池未正确完成的问题，但在以前的端点-v1 和 java7 中不知何故不存在。同时，我们看到每个实例报告了 0 个错误（这是不正确的，它一直在大约 10 到 30 秒后中止请求）并且我们无法获得任何堆栈跟踪来查看请求像以前一样中止的位置。

杀死/重启一个实例会在一段时间内解决 10s 的问题，但这自然不是解决方案。

是否必须采取任何步骤才能实现 v2 承诺的性能改进？

4

2 回答 2

4

TL;DR -单独的 GCE 2.0 比 GCE 1.0 更快、更可靠，但不要使用 API 管理，否则你会回馈所有这些收益，然后是一些收益。

在测试 GCE 2.0 时，我也看到了严重的缓慢问题，而且我无法证明让我的用户遭受如此可怕的延迟下降是合理的，所以我开始确定发生了什么。

这是我的方法：

我使用 Endpoints 1.0、Endpoints 2.0 和 Endpoints 2.0 with API Management 设置了一个最小可行的 App Engine 应用程序，该应用程序仅包含一个简单的 API 调用，该调用返回服务器时间戳。您可以在此处查看所有这些代码：https ://github.com/ubragg/cloud-endpoints-testing

我将它们中的每一个部署到一个单独的 App Engine 应用程序中，并在这些链接上使用 API Explorer 测试了 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 Explorer 报告的客户端角度来看的。以下是服务器在同一时间段内报告的来自 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 .

于 2018-03-22T22:44:27.610 回答
2

使用没有管理库的基本 API 框架（您提到的 14ms 调用是其中的一部分），您应该得到一些改进的延迟。v2 框架中的内存使用有所增加，因为它现在合并了以前是单独服务的代码。如果您不使用 API 管理，我建议您删除该库并查看它是否有帮助。它应该消除 14 毫秒的延迟并减少相当多的内存使用，因为您不会加载太多的代码或数据。

于 2017-08-10T20:56:51.483 回答