amazon-web-services - API 网关是否引入了显着延迟？

Question

我试图弄清楚我的通话中的延迟来自哪里，请让我知道是否可以以更清晰的格式呈现这些信息!

一些背景知识:我有两个系统——系统 A 和系统 B。我手动(通过 Postman)点击系统 A 上的一个端点，该端点调用系统 B 上的一个端点。
系统 A 托管在 EC2 实例上。

当系统 B 托管在 API Gateway 后面的 Lambda 函数上时，
调用延迟为 125 毫秒。

当系统 B 托管在
EC2 实例，调用延迟为 8 毫秒。

当系统 B 是
托管在 API Gateway 后面的 EC2 实例上，
通话时间为 100 毫秒。

因此，我的假设是 API 网关也是与 Lambda 函数配对时延迟增加的原因。任何人都可以确认是否是这种情况，如果是这样，API Gateway 做了什么会大大增加延迟？有什么办法吗？谢谢!

Answer 1

这可能不是最初的问题所要求的，但我会添加关于 的评论。云端 .

根据我的经验，CloudFront 和 API Gateway 平均每个 HTTPS 请求都会增加至少 100 毫秒 - 甚至可能更多。

This is due to the fact that in order to secure your API call, API Gateway enforces SSL in all of its components. This means that if you are using SSL on your backend, that your first API call will have to negotiate 3 SSL handshakes:

1. Client to CloudFront
2. CloudFront to API Gateway
3. API Gateway to your backend

It is not uncommon for these handshakes to take over 100 milliseconds, meaning that a single request to an inactive API could see over 300 milliseconds of additional overhead. Both CloudFront and API Gateway attempt to reuse connections, so over a large number of requests you’d expect to see that the overhead for each call would approach only the cost of the initial SSL handshake. Unfortunately, if you’re testing from a web browser and making a single call against an API not yet in production, you will likely not see this.

在同一个讨论中，最终澄清了“大量请求”应该是什么才能真正看到连接重用:

Additionally, when I meant large, I should have been slightly more precise in scale. 1000 requests from a single source may not see significant reuse, but APIs that are seeing that many per second from multiple sources would definitely expect to see the results I mentioned.

...

Unfortunately, while cannot give you an exact number, you will not see any significant connection reuse until you approach closer to 100 requests per second.

请记住，这是 2016 年中后期的一个帖子，应该已经有了一些改进。但根据我自己的经验，这种开销仍然存在，并且在 2000 rps 的简单 API 上执行负载测试，到 2018 年仍然给我带来超过 200 毫秒的额外延迟。

来源:https://forums.aws.amazon.com/thread.jspa?messageID=737224