Firebase功能会延迟冷启动时间

Question

我在这里读到端点旋转应该是透明的，我认为这意味着冷启动时间不应与常规执行时间不同。还是这样吗？在所有端点上，我们的启动速度非常缓慢且无法使用，大约为16秒。

冷启动： Function execution took 16172 ms, finished with status code: 200 之后：Function execution took 1002 ms, finished with status code: 304

这是预期的行为，可能是什么原因造成的？

Answer 1

更新：至少对于我来说，冷启动时间似乎不再是节点8的问题。对于那些对通过App Engine进行cron任务保持功能温暖的人，我将在下面留下我的答案。但是，还有一种新的cron方法可用，可以使它们更容易保暖。有关cron和Firebase的更多详细信息，请参见firebase博客。

我的冷启动时间太荒谬了，以至于浏览器将在等待请求时超时。（例如，正在等待Firestore API完成）。

示例 一个函数，该函数创建一个新的用户帐户（auth.user（）。onCreate trigger），然后在firestore中设置一个用户配置文件。

• 部署后首次启动：持续30到60秒之间，经常在寒冷时进行首次尝试时给我一个“连接错误”（这是在Firebase CLI说“部署完成！”之后等待了几秒钟）
• 冷启动：10-20秒
• 暖时：所有这些操作大约在400毫秒内完成。

可以想象，没有多少用户会等待几秒钟来设置帐户。我也不能只让这种情况在后台发生，因为它是应用程序过程的一部分，该过程需要配置文件设置来存储输入数据。

我的解决方案是向所有API添加“ ping”功能，并创建一个类似于cron的调度程序任务，以便使用应用程序引擎每分钟对我的每个功能执行ping操作。

确保ping功能可以执行某些操作，例如访问Firestore文档或设置新的用户帐户，而不仅仅是响应http请求。

请参阅此教程以了解App引擎的日程安排：https : //cloud.google.com/appengine/docs/flexible/nodejs/scheduling-jobs-with-cron-yaml

Answer 2

嗯，我想这是关于云功能的资源使用，我也在那里。当您的函数空闲时，云函数也会释放其资源，第一次调用时它会重新分配这些资源，第二次调用时您就可以了。我不能说这是好还是不好，但事实就是如此。