如何让 Google Cloud Functions 保持温暖? [英] How can I keep Google Cloud Functions warm?
问题描述
我知道这可能首先忽略了使用 Cloud Functions 的要点，但在我的特定情况下，我使用 Cloud Functions 是因为这是我可以将 Next.js 与 Firebase Hosting 桥接的唯一方法.我不需要让它具有成本效益等.
I know this may miss the point of using Cloud Functions in the first place, but in my specific case, I'm using Cloud Functions because it's the only way I can bridge Next.js with Firebase Hosting. I don't need to make it cost efficient, etc.
话虽如此，Cloud Functions 的冷启动时间简直令人无法忍受，而且还没有做好生产准备，对于我的样板，平均大约 10 到 15 秒.
With that said, the cold boot times for Cloud Functions are simply unbearable and not production-ready, averaging around 10 to 15 seconds for my boilerplate.
我看过这个由 Google 提供的视频 (https://www.youtube.com/watch?v=IOXrwFqR6kY) 讨论如何减少冷启动时间.简而言之:1) 修剪依赖项，2) 试用 &Google 网络上缓存的依赖项版本错误，3) 延迟加载.
I've watched this video by Google (https://www.youtube.com/watch?v=IOXrwFqR6kY) that talks about how to reduce cold boot time. In a nutshell: 1) Trim dependencies, 2) Trial & error for dependencies' versions for cache on Google's network, 3) Lazy loading.
但是 1) 我只能修剪这么多的依赖项.2)我怎么知道哪个版本缓存更多?3) 只有这么多依赖项我可以延迟加载.
But 1) there are only so many dependencies I can trim. 2) How would I know which version is more cached? 3) There are only so many dependencies I can lazy load.
另一种方法是避免冷启动.有什么好方法或技巧可以让我的(一个且唯一的)云功能保持温暖?
Another way is to avoid the cold boot all together. What's a good way or hack that I can essentially keep my (one and only) cloud function warm?
推荐答案
所有无服务器"计算提供商，总会有某种形式的冷启动成本是您无法消除的.即使您能够通过 ping 单个实例使其保持活动状态，系统也可能会启动任意数量的其他实例来处理当前负载.这些新实例将产生冷启动成本.然后，当负载减少时，将关闭不需要的实例.
With all "serverless" compute providers, there is always going to be some form of cold start cost that you can't eliminate. Even if you are able to keep a single instance alive by pinging it, the system may spin up any number of other instances to handle current load. Those new instances will have a cold start cost. Then, when load decreases, the unnecessary instances will be shut down.
正如您所发现的，有一些方法可以最大限度地降低冷启动成本，但无法消除这些成本.
There are ways to minimize your cold start costs, as you have discovered, but the costs can't be eliminated.
自 2021 年 9 月起，您现在可以指定最少数量的实例以保持活动状态.这有助于减少(但不能消除)冷启动.阅读 Google Cloud 博客 和
As of Sept 2021, you can now specify a minimum number of instances to keep active. This can help reduce (but not eliminate) cold starts. Read the Google Cloud blog and the documentation. For Firebase, read its documentation. Note that setting min instances incurs extra billing - keeping computing resources active is not a free service.
如果您绝对需要热服务器来处理 24/7 的请求，那么您需要管理自己的 24/7 全天候运行的服务器(并支付那些 24/7 运行的服务器的费用).如您所见，无服务器的好处在于您无需管理或扩展自己的服务器，您只需为使用的内容付费，但您的项目冷启动成本不可预测.这就是权衡.
If you absolutely demand hot servers to handle requests 24/7, then you need to manage your own servers that run 24/7 (and pay the cost of those servers running 24/7). As you can see, the benefit of serverless is that you don't manage or scale your own servers, and you only pay for what you use, but you have unpredictable cold start costs associated with your project. That's the tradeoff.
这篇关于如何让 Google Cloud Functions 保持温暖?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
