API网关引入了重要延迟吗？

Question

我正在试图找出通话中的延迟来自哪里，如果有任何此类信息可以更清晰的格式呈现，请告诉我们。

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

• 当系统B托管在API网关后面的Lambda函数上时， 呼叫延迟为125毫秒。
• 当系统B托管在 在EC2实例中，呼叫的延迟是8毫秒。
• 当系统B是 托管在API网关后面的EC2实例上，延迟了 电话是100毫秒。

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

Answer 1

在直接案例（＃2）中您使用的是SSL吗？ SSL的速度为8毫秒非常快，但如果它在AZ中，我认为它是可能的。如果您没有在那里使用SSL，那么使用API​​GW将在客户端和CloudFront之间引入安全的TLS连接，这当然会有延迟损失。但通常这对于安全连接是值得的，因为延迟仅在初始建立时。

一旦建立连接，或者当API具有适度的持续音量时，我预计APIGW的平均延迟会显着下降。在建立新连接时，您仍会看到~100 ms的延迟。

不幸的是，您正在描述的用例（EC2 - ＆gt; APIGW - ＆gt; EC2）现在并不是很好。由于APIGW落后于CloudFront，因此它针对全球客户进行了优化，但当客户端使用EC2时，您会看到额外的延迟。

编辑： 而且你在添加Lambda时只看到一个小的惩罚的原因是APIGW已经与Lambda建立了许多已建立的连接，因为它是一个拥有少量IP的单个端点。 APIGW中的实际开销（不是连接相关）应该类似于Lambda开销。

Answer 2

听取亚马逊对此的支持：

  

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

     

因此预计会出现这种额外延迟。降低的唯一方法   延迟是在API缓存中添加，这只是有用的   如果您要求的内容是静态的而不是   不断更新。你仍会看到更长的延迟时间   item从缓存中删除，需要从系统中获取，   但它会降低大多数电话。

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

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握手的成本。不幸的是，如果您正在通过网络浏览器进行测试并针对尚未投入生产的API进行单次调用，您可能不会看到这一点。

在同一个讨论中，最终澄清了实际看到连接重用的“大量请求”应该是什么：

  

另外，当我的意思很大时，我应该在规模上稍微精确一些。来自单一来源的1000个请求可能看不到重要的重用，但是从多个来源看到每秒很多的API肯定会期望看到我提到的结果。

...

  

不幸的是，虽然无法给出确切的数字，但在每秒接近100个请求之前，您将看不到任何重要的连接重用。

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

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