我们刚刚迁移到google cloud端点v2 / java8，发现延迟已经上升。我们经常看到这种请求：
https://servicecontrol.googleapis.com/v1/services/<myapi>.endpoints.<myappid>.cloud.goog:check
使用大约14ms。此外，不知何故，内存使用率上升，我们的B2前端突然开始阻塞并经常延迟10秒，这可能是连接池未正确完成的问题，但是在某种程度上不存在端点-v1＆amp; java7之前。 同时，我们看到每个实例报告0个错误（这不是真的，它一直在大约10-30秒之后中止请求）并且我们无法获得任何堆栈跟踪以查看请求像以前一样被中止的位置。
杀死/重启实例会解决10s问题一段时间，但这自然不是解决方案。
是否需要采取任何措施来实现v2承诺的性能改进？
答案 0 :(得分：3)
TL; DR - GCE 2.0 单独比GCE 1.0更快，更可靠，但不使用API管理，否则您将返还所有这些收益，然后再收回一些。< /强>
我在测试GCE 2.0时也看到了主要的缓慢问题，而且我无法证明让我的用户遭受如此可怕的延迟下降，所以我开始确定发生了什么。
这是我的方法：
我设置了一个最小的可行App Engine应用程序，该应用程序只包含一个简单的API调用，该调用使用Endpoints 1.0，Endpoints 2.0和带有API Management的Endpoints 2.0返回服务器时间戳。您可以在此处查看以下所有代码：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感到好奇，请确保 NOT 遵循此处的任何说明：https://cloud.google.com/endpoints/docs/frameworks/python/adding-api-management。
答案 1 :(得分：2)
使用没有管理库的基础API框架（您提到的14ms调用是其中的一部分），您应该获得一些改进的延迟。 v2框架中的内存使用量有所增加，因为它现在包含以前是单独服务的代码。如果您不使用API管理，我建议删除库并查看它是否有帮助。它应该消除14ms的延迟并减少相当多的内存使用量，因为您不会加载尽可能多的代码或数据。