我知道这可能会错过使用 Cloud Functions 的初衷，但在我的具体情况下，我使用 Cloud Functions 是因为这是我将 Next.js 与 Firebase Hosting 桥接的唯一方法。我不需要使其具有成本效益，等等。
话虽如此，Cloud Functions 的冷启动时间简直令人难以忍受，并且无法投入生产，平均约为 10 到 15seconds对于我的样板。
我在 Google 上看过这个视频（https://www.youtube.com/watch?v=IOXrwFqR6kY）讨论如何减少冷启动时间。简而言之：1）修剪依赖项，2）在 Google 网络上缓存依赖项版本的试验和错误，3）延迟加载。
但是 1）我只能修剪这么多的依赖项。 2）我如何知道哪个版本缓存更多？ 3）我可以延迟加载的依赖项只有这么多。
另一种方法是避免冷启动。有什么好方法或技巧可以让我的（唯一的）云功能保持温暖？
对于所有“无服务器”计算提供商，总会存在某种形式的无法消除的冷启动成本。即使您能够通过 ping 单个实例来使其保持活动状态，系统也可能会启动任意数量的其他实例来处理当前负载。这些新实例将产生冷启动成本。然后，当负载减少时，不必要的实例将被关闭。
正如您所发现的，有多种方法可以最大限度地降低冷启动成本，但这些成本无法消除。
自 2021 年 9 月起，您现在可以指定保持活动状态的最小实例数。这可以帮助减少（但不能消除）冷启动。阅读谷歌云博客和文档。对于 Firebase，请阅读其文档。请注意，设置最小实例会产生额外的费用 - 保持计算资源处于活动状态并不是免费服务。
如果您绝对需要热服务器 24/7 处理请求，那么您需要管理自己的 24/7 运行的服务器（并支付那些 24/7 运行的服务器的成本）。正如您所看到的，无服务器的好处是您无需管理或扩展自己的服务器，并且只需为您使用的内容付费，但与您的项目相关的冷启动成本是不可预测的。这就是权衡。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
