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

Question

问题

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

问题

为什么第一次调用这么慢？是因为身份验证吗？

有什么解决方法吗？

使用 Amazon Lambda/Google Cloud Functions 在 Firebase DB 上进行一些用户启动的数据计算并在 1 - 2 秒内将结果返回给客户端是否可行？

语境

我计划使用 Firebase 的无服务器架构作为我的数据存储库，Amazon Lambda/Cloud Functions 使用一些服务器端计算来增强 Firebase，例如搜索其他用户。我打算通过客户端的 HTTP 请求触发这些功能。

我担心的一个问题是第一次从服务器调用 Firebase 所花费的时间很长。在我的笔记本电脑上测试一些服务器端代码时，第一个监听器在 6 秒内返回!后续调用在 300 - 400 毫秒内返回。数据集非常小(2 - 3 个键值对)，我还通过交换观察者进行了测试。

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

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

Answer 1

TL;博士:您注意到了一些已知/预期的事情，尽管随着 GA 的临近，我们会减少惩罚。一些改进迟早会到来。

此处为 Firebase 团队成员的 Cloud Functions。我们能够通过在持续缺乏负载后“缩放到零”(关闭所有实例)以具有竞争力的价格提供 Cloud Functions。当收到请求而您没有可用实例时，Cloud Functions 会按需为您创建一个。这显然比访问事件服务器慢，我们称之为“冷启动”。冷启动是“无服务器”架构现实的一部分，但我们有很多人致力于研究显着减少惩罚的方法。

还有另一种情况，我最近开始称之为“不冷不热”的开始。部署后，Cloud Function 实例已创建，但您的应用程序仍有预热工作要做，例如建立与 Firebase 实时数据库的连接。正如您所建议的，其中一部分是身份验证。我们检测到这里的放缓将在下周修复。之后，您仍然需要为 SSL + Firebase 握手付费。尝试测量这个延迟；目前尚不清楚我们能够在多大程度上规避它。