javascriptnode.jsgoogle-cloud-platformgoogle-cloud-functionscold-start

Does the size of the node_modules folder matters during cold starts for cloud functions?

I know that you should only import the required modules inside the index file's global scope to reduce the time of the cold starts.

But I haven't yet found out that if the size of the node_modules folder (or the length of the dependencies property of the package.json file) matters for cold starts in case of cloud functions or only the imported modules count?

Solution

  • The size doesn't matter! When you publish your code, a container is built (with buildpacks). This container is cached and so, when the function start, the container don't have to be downloaded.

    There, the size don't impact the startup time (because there isn't download).

    HOWEVER, a large node_modules folder (and more generally, in any languages, a large number of dependencies) can mean a lot of things initialized at startup (services, connexion to database,...). If it's in eager mode, that increases the startup duration.

    Prefer a lazy initialization of your components, even the global ones. Prefer also the light frameworks (or no framework) instead of big Berta!!

    EDIT

    There is no cache policy management for the functions version. When a version is built and active, the image is cached, that's all. When a new is built, the previous will be evicted, a day. You can't manage this, it's serverless!

    To insist on the size doesn't matter, I found 2 links about Cloud Run. Yes, Cloud Run!! In fact, Cloud Run and Cloud Functions share the same backend and the same behavior (your function is packaged in a container (as explained before) and served with the same logic as the Cloud Run containers)

    So, here the official Google documentation and an unofficial FAQ maintained by a guru of Cloud Run (Ahmet, Dev Advocate on Cloud Run @Google)

    Eventually, the size doesn't matter, but I found that the language matters!! In this article also wrote by a Googler, there is an explanation of NodeJS startup behavior

    When a module boots, node.js resolves all require() calls from the entry point using synchronous I/O, which can take a significant amount of time if the number of dependencies are large, or if the content itself requires a lot of linking.

    So, it's more a language problem and optimization to perform (lazy loading?) than a platform issue. The article provides many way to optimize the code!