为什么来自服务器的第一个Firebase呼叫比后续呼叫需要更长的时间才能返回？

Question

问题

首先从服务器调用Firebase所需的时间比后续调用长约15 - 20倍。虽然这对于调用Firebase的传统服务器来说不是问题，但它可能会导致利用Amazon Lambda / Google Cloud功能的无服务器架构出现问题。

问题

• 为什么第一次通话要慢得多？这是由于身份验证吗？
• 有没有变通办法？
• 使用Amazon Lambda / Google Cloud Functions在Firebase数据库上进行一些用户启动的数据计算并在1-2秒内将结果返回给客户端是否切实可行？

上下文

我计划使用Firebase作为我的数据存储库的无服务器架构和Amazon Lambda / Cloud Functions，通过一些服务器端计算扩充Firebase，例如：正在搜索其他用户。我打算通过客户端的HTTP请求触发函数。

我遇到的一个问题是从服务器第一次调用Firebase所花费的时间很长。在笔记本电脑上测试一些服务器端代码时，第一个监听器会在6s内返回！后续呼叫返回300 - 400ms。数据集非常小（2到3个键值对），我也通过交换观察者来测试。

相比之下，从笔记本电脑调用Google Maps API大约需要400毫秒才能返回。

我意识到服务器的响应时间会快得多。第一次通话仍然是15-20倍的因素令人不安。

Answer 1

TL; DR：你注意到已知/预期的事情，尽管我们会在GA接近时削减惩罚。一些改进将比以后更快。

此处为Firebase团队成员提供云功能。我们能够在持续缺乏负载后通过“缩小到零”（关闭所有实例）以具有竞争力的价格提供云功能。当请求进入且您没有可用实例时，云功能会根据您的需要为您创建一个。这显然比点击活动服务器慢，我们称之为“冷启动”。冷启动是“无服务器”架构的现实的一部分，但是我们有很多人在努力减少惩罚。

还有一个案例，我最近开始称之为“不冷不热”的开始。部署之后，已创建Cloud Function实例，但您的应用程序仍然需要进行预热工作，例如建立与Firebase实时数据库的连接。正如您所建议的那样，此的一部分是身份验证。我们在这里发现了一个将在下周修复的减速。之后，您仍然需要支付SSL + Firebase握手费用。尝试测量这种延迟;目前尚不清楚我们能够绕过它多少。

Answer 2

谢谢弗兰克！阅读firebase如何建立Web套接字连接。

要添加到Frank的答案，初始握手会导致第一次拉动延迟。该方法大大加快了后续的数据拉动速度。在美国西海岸服务器上运行的Amazon Lambda实例上进行测试时。响应时间为：1）第一次拉动：1.6 - 2.3s 2）后续拉动：60 - 100ms 。数据集本身非常小，因此可以假设这些时间段仅用于服务器到服务器的通信。外卖：

• Amazon Lambda实例可以通过API网关触发，用于非时间关键型计算，但不是Firebase数据实时计算的理想解决方案，例如返回搜索结果（除非有办法保证持久握手）实例 - 而不是我所读过的内容
• 对于时间关键型计算，我打算运行利用Firebase队列的EC2 / GAE实例。 https://github.com/firebase/firebase-queue。该方法比触发lambda实例更复杂，但会更快地返回结果（因为避免了每个任务的握手）。