问题
首先从服务器调用Firebase所需的时间比后续调用长约15 - 20倍。虽然这对于调用Firebase的传统服务器来说不是问题，但它可能会导致利用Amazon Lambda / Google Cloud功能的无服务器架构出现问题。
问题
上下文
我计划使用Firebase作为我的数据存储库的无服务器架构和Amazon Lambda / Cloud Functions，通过一些服务器端计算扩充Firebase，例如：正在搜索其他用户。我打算通过客户端的HTTP请求触发函数。
我遇到的一个问题是从服务器第一次调用Firebase所花费的时间很长。在笔记本电脑上测试一些服务器端代码时，第一个监听器会在6s内返回！后续呼叫返回300 - 400ms。数据集非常小（2到3个键值对），我也通过交换观察者来测试。
相比之下，从笔记本电脑调用Google Maps API大约需要400毫秒才能返回。
我意识到服务器的响应时间会快得多。第一次通话仍然是15-20倍的因素令人不安。
答案 0 :(得分：9)
TL; DR：你注意到已知/预期的事情，尽管我们会在GA接近时削减惩罚。一些改进将比以后更快。
此处为Firebase团队成员提供云功能。我们能够在持续缺乏负载后通过“缩小到零”（关闭所有实例）以具有竞争力的价格提供云功能。当请求进入且您没有可用实例时，云功能会根据您的需要为您创建一个。这显然比点击活动服务器慢，我们称之为“冷启动”。冷启动是“无服务器”架构的现实的一部分，但是我们有很多人在努力减少惩罚。
还有一个案例，我最近开始称之为“不冷不热”的开始。部署之后，已创建Cloud Function实例，但您的应用程序仍然需要进行预热工作，例如建立与Firebase实时数据库的连接。正如您所建议的那样，此的一部分是身份验证。我们在这里发现了一个将在下周修复的减速。之后，您仍然需要支付SSL + Firebase握手费用。尝试测量这种延迟;目前尚不清楚我们能够绕过它多少。
答案 1 :(得分：1)
谢谢弗兰克！阅读firebase如何建立Web套接字连接。
要添加到Frank的答案，初始握手会导致第一次拉动延迟。该方法大大加快了后续的数据拉动速度。在美国西海岸服务器上运行的Amazon Lambda实例上进行测试时。响应时间为：1）第一次拉动：1.6 - 2.3s 2）后续拉动：60 - 100ms 。数据集本身非常小，因此可以假设这些时间段仅用于服务器到服务器的通信。外卖：