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 的评论。

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

这是因为为了保护您的 API 调用，API Gateway 在其所有组件中强制实施 SSL。这意味着如果您在后端使用 SSL，那么您的第一个 API 调用将必须协商 3 次 SSL 握手：

1. 客户端到 CloudFront
2. CloudFront 到 API 网关
3. 后端的 API 网关

这些握手花费超过 100 毫秒的情况并不少见，这意味着对非活动 API 的单个请求可能会产生超过 300 毫秒的额外开销。 CloudFront 和 API Gateway 都尝试重用连接，因此在大量请求中，您希望看到每次调用的开销仅接近初始 SSL 握手的成本。不幸的是，如果您在 Web 浏览器中进行测试并针对尚未投入生产的 API 进行一次调用，您可能不会看到这一点。

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

此外，当我的意思是大时，我应该在比例上稍微精确一些。来自单一来源的 1000 个请求可能不会得到显着的重用，但是每秒从多个来源看到这么多请求的 API 肯定会看到我提到的结果。

...

很遗憾，虽然无法为您提供确切的数字，但在您接近每秒 100 个请求之前，您不会看到任何重要的连接重用。

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

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

Answer 2

收到亚马逊支持：

使用 API Gateway，它需要从客户端到 API Gateway， 这意味着离开 VPC 并上网，然后返回 到您的 VPC 以转到您的其他 EC2 实例，然后返回 API 网关，这意味着再次离开您的 VPC，然后回到您的 第一个 EC2 实例。

因此，这种额外的延迟是预料之中的。唯一的办法是降低 延迟是添加 API 缓存，这只会有用 如果您请求的内容将是静态的而不是 不断更新。当 项目已从缓存中删除，需要从系统中获取， 但它会降低大多数调用次数。

所以我猜延迟是正常的，这很不幸，但希望不是我们必须不断处理的事情。

Answer 3

在直接情况下（#2），您是否使用 SSL？ 8 毫秒对于 SSL 来说非常快，但如果它在 AZ 内，我想这是可能的。如果您没有在那里使用 SSL，那么使用 APIGW 将在客户端和 CloudFront 之间引入安全的 TLS 连接，这当然会带来延迟损失。但通常这对于安全连接来说是值得的，因为延迟仅在初始建立时。

一旦建立了连接，或者当 API 具有适度、持续的音量时，我预计 APIGW 的平均延迟会显着下降。但是，在建立新连接时，您仍然会看到大约 100 毫秒的延迟。

不幸的是，您所描述的用例（EC2 -> APIGW -> EC2）现在不是很好。由于 APIGW 落后于 CloudFront，因此它针对世界各地的客户端进行了优化，但是当客户端在 EC2 上时，您会看到额外的延迟。

编辑： 添加 Lambda 时您只会看到一点点损失的原因是 APIGW 已经建立了许多与 Lambda 的连接，因为它是一个带有少量 IP 的单一端点。 APIGW 中的实际开销（与连接无关）应该类似于 Lambda 开销。