为什么来自服务器的第一个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 套接字连接。

为了补充弗兰克的答案，最初的握手会导致第一次拉动的延迟。该方法极大地加快了后续数据提取的速度。在美国西海岸服务器上运行的 Amazon Lambda 实例上进行测试。响应时间为： 1)第一次拉动：1.6 - 2.3 秒2)后续拉动：60 - 100 毫秒。数据集本身非常小，因此可以假设这些时间段仅用于服务器到服务器的通信。要点：

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