Comments (11)
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.
Related Issues (20)
- all revalidation options trigger 503 error HOT 5
- Serverless-Next.js deployment not updating the EdgeLambda version to latest in Cloudfront cache behaviour mapping HOT 1
- Using package with github actions some inline css not loading
- serverless-patched with pnpm is broken HOT 1
- Incremental Static Regeneration Not working when lambda handler is added
- Nextjs 12 plugin version for manual regerneration of page ISR HOT 10
- Next 13 - future plans - Is serverless-next.js dead? HOT 61
- I can't deploy with Next v12.3.1 and @sls-next/serverless-component v3.7.0. CloudFront returns 503 HOT 6
- Error [UriParameterError]: Expected uri parameter to have length >= 1
- Unable to customize allowed and cached HTTP methods for default behaviour HOT 1
- Buckets are being deleted unintentionally when deploying multiple apps from one code base HOT 5
- Make creating a new build optional HOT 1
- [nextjs-cdk-construct] Allow specifying the name for the the image origin request policy
- Getting "The Lambda function associated with the CloudFront distribution was throttled" error
- Failing to generate new pages after build(ISR) HOT 1
- Module parse failed: Unexpected token HOT 2
- Problems to see logs
- [sharp version update] sharp used in imageLambda 0.28.3 now HOT 1
- Combine serverless-next.js CF distribution with other distributions denies access on S3
- Everytime I deploy my app through nextjs serverless, it creates user defined cost allocation tags, although I dont have permission to create those tags in aws. How to disable this? I couldn't find that in the documentation.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from serverless-next.js.