API网关会引入明显的延迟吗？

Question

我正在尝试弄清楚通话中的延迟来自何处，请让我知道是否可以使用更清晰的格式来显示这些信息！

背景知识：我有两个系统-系统A和系统B。我手动（通过Postman）命中了系统A上的一个端点，该端点调用了系统B上的端点。系统A托管在EC2实例上。

• 当系统B托管在API网关后面的Lambda函数上时，调用的延迟为125毫秒。
• 当系统B托管在EC2实例上时，呼叫的等待时间为8毫秒。
• 当系统B托管在API网关后面的EC2实例上时，该呼叫的等待时间为100毫秒。

因此，我的假设是当API网关与Lambda函数搭配使用时，也是导致延迟增加的原因。任何人都可以确认是否是这种情况，如果是这样，API网关在做什么，这会大大增加延迟？有什么办法解决吗？谢谢！

Answer 1

从亚马逊的支持中得知：

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

所以这个额外的延迟是意料之中的。降低延迟的唯一方法是添加 API 缓存，这在您请求的内容将是静态的并且不会不断更新时才有用。当项目从缓存中移除并需要从系统中获取时，您仍然会看到更长的延迟，但它会降低大多数调用。

所以我想延迟是正常的，这是不幸的，但希望不是我们必须不断前进的事情。

Answer 2

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

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

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

编辑：添加 Lambda 时只看到很小的惩罚的原因是 APIGW 已经与 Lambda 建立了许多连接，因为它是具有少量 IP 的单个端点。APIGW 中的实际开销（与连接无关）应与 Lambda 开销类似。

Answer 3

它可能与原始问题所要求的不完全相同，但是我将添加有关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年中后期的主题，应该已经进行了一些改进。但是以我自己的经验，这种开销仍然存在，并且截至2018年，在具有2000 rps的简单API上执行负载测试仍然给我带来了200毫秒的额外延迟。

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