Question about multiple Lambda code bundles and cold boot times about serverless-next.js HOT 11 CLOSED

Okay you're right - it does look like Express cold boot is what accounts for most of the slowdown:

Bundle size does still seem to make a small difference - but I was only able to do a quick experiment (5 cold + 5 hot starts in each env).

from serverless-next.js.

The lambda, at runtime only requires a single page bundle, regardless of what's inside the deployment artifact. I think this is what makes most of the difference compared to the more traditional monolith approach which at runtime serves all the pages.
However, you're right there could be separate deployment artifacts per Lambda each with the separate page bundles, which in theory should improve the time involved in downloading the artifact from the Lambda.
I'm going to close this in favour of a feature request #49.
Thanks!

from serverless-next.js.

Yes, I saw that only a single require was used per page - I can see how this should have a big impact. Instinctively it feels like the size of each bundle should also affect cold start but interestingly this article suggests that it does not https://read.acloud.guru/does-coding-language-memory-or-package-size-affect-cold-starts-of-aws-lambda-a15e26d12c76

Thanks for raising the feature 👍

from serverless-next.js.

Yeah read the same article! I do however feel like the individual artefacts make more sense, especially considering it's easy to implement and shouldn't affect anything else, so will have a look when I get a chance 👍

from serverless-next.js.

BTW - just to follow up on this. Bundle size did indeed make a difference to cold start times when I tested this (using 3mb Lambda):

This was measuring actual TTFB / request latency (not CloudWatch - which I think does not report on bootstrap times).

from serverless-next.js.

How do you know is bundle size and not the overhead added by express? I expect the bootstrap times for express to be higher.

from serverless-next.js.

Yeah that's fair but I think that should be reflected in the difference in hot start time I.e. slower by ms not seconds. I will try large single page bundle to verify though.

from serverless-next.js.

@danielcondemarin I'm starting to wonder whether it actually might be better to keep a single bundle?

Also, now not sure what benefits of Next.js "serverless" approach is i.e. self-contained page-level JS files. I can only imagine is slows down builds (imagine 50x page-level JS files, each of which has same dependencies baked in e.g. React), means more Lambdas to manage (using Terraform / Serverless etc. - and potential CloudFormation resource limit issues from latter) vs. just having single bundle, single Lambda + v. lightweight routing (not Express). I feel like I must be missing something - perhaps I need to experiment a bit more :)

from serverless-next.js.

Next serverless approach means horizontally scalable pages. For example, doesn't matter how much your bundle size grows you'll never hit a Lambda size limit. The same applies to the Lamba memory, with one lambda for everything you can only scale that vertically.

The management aspect you could argue that serverless is doing that for you. I would ask what is it difficult to manage?

In terms of the CF limits you're absolutely right, that's an issue. At some point I hope Amazon increases the limit or serverless introduces some workaround for it but seems like that might take a while.

from serverless-next.js.

Yeah, I want to believe in the above but I can't imagine practically hitting bundle size limits for lambda with single app (at least for projects I'm thinking of).

In terms of scaling only certain pages over others I'm not really sure how this results in better performance tbh (can't imagine it really affects number of cold boots). Being able to choose memory per lambda is good but not useful for us atm.

This plugin is great for managing deployment (although it may not be an option for us).

I think there are some arguments about isolation and with that better security and perhaps the potential to deploy only changed Lambdas? The speed improvements at the moment may come from having single code by bundle vs. requiring into node_modules.

Anyway, thanks for your time - I should take this question to the Next.js forum.

from serverless-next.js.

@willbamford Thought to let you know about the new next component release. I believe it addresses some of your concerns above :)

from serverless-next.js.