如何解决云功能的冷启动期间,node_modules文件夹的大小是否重要?
我知道您应该只在索引文件的全局范围内导入所需的模块,以减少冷启动的时间。
但是我还没有发现,如果有云功能或仅导入的模块计数,node_modules文件夹的大小(或package.json文件的依赖属性的长度)是否对冷启动很重要?
解决方法
大小无关紧要!发布代码时,将构建一个容器(带有buildpacks)。此容器已缓存,因此,在函数启动时,不必下载该容器。
在这里,大小不会影响启动时间(因为没有下载)。
HOWEVER ,一个大的node_modules文件夹(更常见的说,在任何一种语言中,都有大量的依赖项)可能意味着很多事情在启动时就初始化了(服务,与数据库的连接,... )。如果它处于急切模式,则会增加启动时间。
最好延迟组件的初始化,即使是全局的。更喜欢轻框架(或没有框架),而不是大的Berta!
编辑
该功能版本没有缓存策略管理。构建并激活一个版本后,便会缓存图像。建造新建筑时,前一天将被驱逐。您无法管理,它是无服务器的!
要坚持大小无关紧要,我找到了两个有关Cloud Run的链接。是的,Cloud Run!实际上,Cloud Run和Cloud Functions共享相同的后端和相同的行为(您的功能打包在一个容器中(如前所述),并与Cloud Run容器具有相同的逻辑)
因此,这里的official Google documentation和unofficial FAQ由Cloud Run专家(Ahmet,Cloud Run @Google的开发倡导者)维护
最终,大小无关紧要,但是我发现语言很重要!!在this article also wrote by a Googler中,有NodeJS启动行为的说明
模块启动时,node.js使用同步I / O解决从入口点开始的所有require()调用,如果依赖项数量很大,或者内容本身需要很多链接。
因此,执行(延迟加载?)要比平台问题更多是语言问题和优化。本文提供了许多优化代码的方法!
,在部署云功能时,Google会根据您位于GCS中的代码源创建一个图像。该映像将嵌入源代码运行所需的所有运行时库。每次您需要函数的新实例时,Google都会从该图像启动一个容器。
现在,容器“物理”将启动时间与图像大小直接相关。映像越薄,启动时间越短。是的,这很重要:)
official GCP page中的更多信息。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。