为了尽量减少冷启动,我为我的Google函数设置了一个最小实例。实际上,我是在中这样做的:
functions.runWith({ minInstances: 1 })...but我可以在Google控制台中看到它的确认:

我注意到,在每次部署之后,我仍然会遇到一个冷酷的开始。我会假设一个实例已经准备好并为第一个请求做好了准备,但情况似乎并非如此。例如,下面是日志:

您可以看到,在部署16小时后,第一个请求就出现了。这是一个寒冷的开端,需要8139毫秒。下一个请求大约在一个小时后出现,但是没有冷启动,请求需要556‘s,比第一个请求要快得多。
那么,这就是人们所期望的行为吗?即使设置了最小的实例,我们仍然会遇到一个冷启动吗?那么,在每次部署之后,我是否应该使用一个虚拟请求来启动云功能,以防止我的用户遇到第一个冷启动呢?
发布于 2022-01-24 01:00:03
文档并没有对这种行为做出严格的保证(重点是我的):
为了尽量减少冷启动的影响,Cloud 尝试在处理请求之后,使未指定的时间保持空闲。
因此,有一次尝试(不能保证),它在处理请求之后(而不是在部署之后)开始,但是您不知道这将持续多长时间。如前所述,听起来您可能想提出一个请求,并期望它可能仍然不总是按照您想要的方式工作。
发布于 2022-01-24 16:47:10
Tl;dr:具有最小实例设置的函数的第一次执行在技术上不是一个冷开始,但可能比以后执行该实例的速度慢。
函数的最小实例将在部署时立即“热身”,处于温暖但空闲的状态,可以响应请求。然而,我们编写的函数通常需要在第一次实际触发时执行额外的设置工作。
例如,我们可以使用动态导入来导入库,或者需要设置到远程DB的连接。即使函数实例是温暖的,在第一次执行时必须完成的额外工作意味着它可能比以后的执行要慢。
最小实例设置的好处是,以后的执行将受益于第一次执行时完成的所有安装工作,并且比将其缩减到零并在下一个请求中必须重新设置自身的速度要快得多。
Cloud :偶尔,Cloud后端可能会杀死一个空闲实例。如果发生这种情况,将立即拆分另一个实例以满足所需的最小实例设置,但该新实例需要在第一次触发时再次完成其额外的设置工作。然而,这种情况不应该经常发生。
https://stackoverflow.com/questions/70827922
复制相似问题