为什么来自服务器的第一个Firebase调用返回所需的时间比后续的调用要长得多? [英] Why does the first Firebase call from the server take much longer to return than subsequent calls?

问题描述

问题

从服务器到Firebase的首次呼叫花费的时间比后续呼叫大约15-20倍.对于使用Firebase的常规服务器而言，这不是问题，但可能会导致利用Amazon Lambda/Google Cloud Functions的无服务器架构出现问题.

First call to Firebase from a server takes ~15 - 20X longer than subsequent calls. While this is not a problem for a conventional server calling upon Firebase, it may cause issues with a server-less architecture leveraging Amazon Lambda/ Google Cloud Functions.

问题

• 为什么第一个电话这么慢?是由于身份验证吗?
• 有没有解决方法?
• 使用Amazon Lambda/Google Cloud Functions在Firebase DB上进行一些用户启动的数据计算并将结果在1-2秒内返回给客户端是否可行?

上下文

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

I am planning on using a server-less architecture with Firebase as the repository of my data and Amazon Lambda/ Cloud Functions augmenting Firebase with some server-side computation, e.g. searching for other users. I intend to trigger the functions via HTTP requests from my client.

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

One concern that I had was the large time taken by the first call to Firebase from the server. While testing some server-side code on my laptop, the first listener returns back in 6s! Subsequent calls return in 300 - 400ms. The dataset is very small (2 - 3 key value pairs) and I also tested by swapping the observers.

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

In comparison, a call to the Google Maps API from my laptop takes about 400ms to return.

我意识到服务器的响应时间会大大加快.在第一次通话时，仍然有15到20倍的数据令人不安.

I realise that response times would be considerably faster from a server. Still a factor of 15 - 20X on the first call is disconcerting.

推荐答案

TL; DR::您注意到的是已知/预期的内容，尽管随着GA的临近我们将减少罚款.某些改进将迟于实现.

TL;DR: You're noticing something that's known/expected, though we will shave the penalty down as GA approaches. Some improvements will come sooner than later.

Firebase团队成员的Cloud Functions.在持续缺乏负载后，我们可以通过降为零"(关闭所有实例)以具有竞争力的价格提供云功能.收到请求后，如果您没有可用的实例，Cloud Functions会根据需要为您创建一个.显然，这比击中活动服务器要慢，这就是我们所说的冷启动".冷启动是无服务器"体系结构现实的一部分，但是我们有很多人正在研究如何显着减少惩罚.

Cloud Functions for Firebase team member here. We are able to offer Cloud Functions at a competitive price by "scaling to zero" (shutting down all instances) after sustained lack of load. When a request comes in and you have no available instances, Cloud Functions creates one for you on demand. This is obviously slower than hitting an active server and is something we call a "cold start". Cold starts are part of the reality of "serverless" architecture, but we have many people working on ways to reduce the penalty dramatically.

还有另一种情况，我最近开始称其为不冷不热"的开始.部署后，已经创建了Cloud Function实例，但是您的应用程序仍然需要进行预热工作，就像建立与Firebase Realtime Database的连接一样.正如您所建议的，此的一部分是身份验证.我们发现此处的速度下降将在下周得到解决.之后，您仍然需要为SSL + Firebase握手付费.尝试测量此延迟；尚不清楚我们有多少钱可以规避它.

There's another case that I've recently started calling a "lukewarm" start. After a deploy, the Cloud Function instance has been created, but your application still has warmup work to do like establishing a connection to the Firebase Realtime Database. Part of this is authentication, as you've suggested. We have detected a slowdown here that will be fixed next week. After that, you'll still have to pay for SSL + Firebase handshakes. Try measuring this latency; it's not clear how much we'll be able to circumvent it.

这篇关于为什么来自服务器的第一个Firebase调用返回所需的时间比后续的调用要长得多?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！