我知道您应该只在索引文件的全局范围内导入所需的模块，以减少冷启动的时间。
但是我还没有发现 node_modules 文件夹的大小（或 package.json 文件的 dependencies 属性的长度）是否对云功能的冷启动很重要，或者只计算导入的模块？
问问题
356 次
2 回答
4
大小无所谓！当您发布代码时，会构建一个容器（使用buildpacks）。这个容器是缓存的，所以当函数启动时，容器不必被下载。
在那里，大小不会影响启动时间（因为没有下载）。
然而，一个大的 node_modules 文件夹（更一般地说，在任何语言中，大量的依赖项）可能意味着在启动时初始化了很多东西（服务、与数据库的连接......）。如果它处于急切模式，则会增加启动持续时间。
更喜欢组件的延迟初始化，甚至是全局组件。也更喜欢轻框架（或无框架）而不是大伯塔！
编辑
函数版本没有缓存策略管理。当一个版本被构建并激活时，图像被缓存，仅此而已。当一个新的建成时，前一个将被驱逐，一天。你无法管理它，它是无服务器的！
为了坚持大小无所谓，我找到了 2 个关于 Cloud Run 的链接。是的，云跑！！实际上，Cloud Run 和 Cloud Functions 共享相同的后端和相同的行为（您的函数被打包在一个容器中（如前所述）并使用与 Cloud Run 容器相同的逻辑提供服务）
因此，这里是由 Cloud Run 的一位大师（Ahmet，Cloud Run 上的 Dev Advocate @Google）维护的官方 Google 文档和非官方常见问题解答
最终，大小无关紧要，但我发现语言很重要！在这篇也是谷歌人写的文章中，有对NodeJS启动行为的解释
当一个模块启动时，node.js 使用同步 I/O 解析来自入口点的所有 require() 调用，如果依赖的数量很大，或者内容本身需要大量链接，这可能会花费大量时间.
因此，与其说是平台问题，不如说是语言问题和执行优化（延迟加载？）。文章提供了很多优化代码的方法！
于 2020-09-27T19:12:01.830 回答
1
当您部署云功能时，Google 会在后台从您位于 GCS 中的代码源创建一个图像。此图像将嵌入您的源代码运行所需的所有运行时库。每次您需要函数的新实例时，Google 都会从该图像启动一个容器。
现在，容器“物理”直接将启动时间与图像大小联系起来。图像越薄，启动时间就越快。所以是的，这很重要:)
更多信息在官方 GCP 页面。
于 2020-09-27T13:55:22.527 回答