I read here端点旋转应该是透明的，我认为这意味着冷启动时间不应与常规执行时间不同。现在还是这样吗？我们的所有端点的冷启动时间都非常慢且无法使用 - 大约 16 秒。
冷启动：Function execution took 16172 ms, finished with status code: 200
After:Function execution took 1002 ms, finished with status code: 304
这是预期的行为吗？可能是什么原因导致的？
UPDATE:冷启动时间似乎不再是节点 8 的问题，至少对我来说是这样。我将在下面留下我的答案，供任何想通过 App Engine 通过 cron 任务保持功能温暖的人。然而，还有一种新的 cron 方法可以更轻松地让它们保持温暖。有关 cron 和 Firebase 的更多详细信息，请参阅 firebase 博客.
我的冷启动时间非常荒谬，以至于浏览器在等待请求时会超时。 （就像它正在等待 Firestore API 完成一样）。
Example创建新用户帐户的函数（auth.user().onCreate 触发器），然后在 firestore 中设置用户配置文件。
-
部署后首次启动：始终在 30 到 60 秒之间，在冷时第一次尝试时经常出现“连接错误”（这是在 Firebase CLI 显示“部署完成！”后等待几秒钟后出现的）
-
冷启动：10 - 20 秒
-
温暖时：所有这些都在大约 400 毫秒内完成。
正如您可以想象的那样，没有多少用户会等待帐户设置超过几秒钟。我也不能让这种情况在后台发生，因为它是需要配置文件设置来存储输入数据的应用程序进程的一部分。
我的解决方案是向我的所有 API 添加“ping”函数，并使用应用程序引擎创建一个类似 cron 的调度程序任务，每分钟对我的每个函数执行 ping 操作。
确保 ping 函数执行某些操作，例如访问 firestore 文档或设置新用户帐户，而不仅仅是响应 http 请求。
请参阅本教程了解应用程序引擎调度：https://cloud.google.com/appengine/docs/flexible/nodejs/scheduling-jobs-with-cron-yaml
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
