5

问题

从服务器首次调用 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 倍仍然令人不安。

4

2 回答 2

11

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

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

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

于 2017-03-12T21:05:28.453 回答
1

谢谢弗兰克！！阅读有关 firebase 如何建立 web-socket 连接的信息。

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

  • Amazon Lambda 实例可以通过 API 网关触发以进行非时间关键型计算，但它不是 Firebase 数据实时计算（例如返回搜索结果）的理想解决方案（除非有一种方法可以保证在实例上保持握手 - 不是从我读过的）
  • 对于时间要求严格的计算，我将使用 Firebase Queue 运行 EC2/GAE 实例。https://github.com/firebase/firebase-queue。该方法比触发 lambda 实例更复杂，但会更快地返回结果（因为避免了每个任务的握手）。
于 2016-10-21T19:56:52.687 回答