Performance over pure lambda functions

[cosbgn]

Hello, I have a question about performance. When I normally deploy a serverless app, each file becomes a serverless function. So if I have 20 routes, those would be 20 separate small files.

With serverless-http my whole app, so all my 20 routes and all my dependencies will become one single lambda function.

Is this something I should be concerned about? I don't have a huge app, but I'm worried that it would perform poorly being fit in one single function.

Thank you!

[SachinShekhar]

You can still split your app based on route. Make sure that API Gateway route and framework (Koa/Express etc) router's route matches. For example, if particular proxy integration's route key is POST /a, then only include code related to /a route like this:

const Router = require('koa-router');
const router = new Router();
router.post('/a', routeAHandler);

expressApp.get('/b', routeBHandler); won't be used, so you can move routeBHandler code to another lambda which is served over GET /b.

This library or lambda doesn't limit you. It'll be the complexity of your legacy apps which might pose difficulty in splitting the app.

[dougmoscrop]

The short answer is you probably don't need to worry, and having them all in one helps with some cold start mitigation. The real answer is always test, use something like 'hey' and tune your memory size with lambda-shearer.

The biggest improvements come from:

• using HTTP API instead of REST (cloudfront adds a lot of latency)
• ensuring you configure the AWS SDK to use http keep alive (not the default)
• provisioning enough memory (use lambda-shearer to test -- sometimes the extra vCPU you get in higher memory really helps, because one core gets busy doing SSL/sigv4 and the other one is still free to do JS stuff)
• minimizing package size

The last one only applies to cold starts, and the second last (memory) applies to both cold start times and execution times (uncreasd throughout to other services, cpu performance, etc.).

I would target function package size as a loose heuristic - aim for single digit MB if you can, and ideally lower like 3-4 MB, if it gets past that start splitting it up along boundaries that make sense (commands/queries, resources..)

[cosbgn]

Thank you both for the very clear and actionable insights (rather than "it depends"). They helped a lot!