Glad it was helpful!

Glad it was helpful!

No worries!

Thanks a lot!

Glad to hear that!

My pleasure Umesh

Thanks for the sub!

haha I love the 1.5x trick

That's a really interesting concept. It should reduce cold starts but can make the code and monitoring the function/s more complicated. You might have 10 errors but you would have to explore further to find out which api caused the error. You can also approximate the amount of cold starts reduced by joining them. If each api is hit very infrequently (few times a day) then adding them will still mean almost all of them are cold starts as not within 10 minutes. If you are getting loads of requests (several a minute or more ) then it probably won't make much difference as the containers aren't getting close to the cool down. Weirdly it might increase them as it means more likely to have concurrent requests. The time it would make a difference would be when you get 3-10 requests an hour. This means the container is cooling off after a large portion of the requests. Joining three Lambdas into one would mean your going from average 12 min between requests (5/hr) to 4 mins. This means the single container is probably never going to cool down. Going through all of this is a lot of work for a few cold starts and as your usage changes your calculations would need to change. If you HAVE to have the quickest lambda times possible then there are ways to prime your lambda with a set of concurrent requests every 5 minutes, ensuring that there are always at least X containers for each lambda. The cost of hitting a lambda 3 times every 5 minutes is also going to be tiny.

Wow that's a lot. Setting up the container should take a few hundred ms. I've not worked with Aurora mysql but it might be that creating a new connection to the database is what is causing the long delay.

There are a few things I would suggest: - If you're not already, use webpack and minify the code when deploying to production. It will reduce your code size and therefore lambda cold start. It will also stop you uploading unnecessary node-modules. - You could use provisioned capacity so you never get a cold start. This does have a cost implication though - write a script to "poke" your lambda every 5 minutes. You can even set this up in serverless as a new event on the function. Search for serverless cron jobs.

@@CompleteCoding oh i forgot to mention the most important thing..its actaully on .net so no web pack minifier for it..though i know about cloud watch rules i had setup something that to poke but in the end it defeats the purpose of paying as u go isnt..and we have likr 400+ lambdas and 20+ api gateways interacting with the i.e. our entire enterprise is on aws...any other solution?

​@@devgenesis6436 If you're lambdas are being hit once every 20 minutes and running for 6s (5s cold start + 1s runtime) then you're using 15GB seconds (GBS) per hour. If you poke it every 5 minutes and the poke lasts 0.1s (minimum lambda run time) and then for just 1s every time it gets a 'real' request then your total is 3 + 12*0.1 = 4.2 GBS. Thats a saving of 78% on your AWS bill! If you used reserved capacity then you have to pay the whole time but with this method, you only pay when it's running.

Yes, every time a new container starts it has to go through all the steps (download, and initialise) before the lambda can run. AWS have done a lot recently to reduce this time even more so unless you're running super latency dependant features it is a minimal problem

Thanks, I'll add it to the list.

So you're trying to get data from Sage every 5 minutes and send that to your database (CMS)? You can create a lambda which automatically runs every 5 minutes. That will then get the data from the Sage API and send it to the database using the API that is part of the CMS (docs.directus.io/reference/api/items/#create-multiple-items). You don't actually need to create your own API for this. Here's the video for creating a scheduled Lambda. kzfaq.info/get/bejne/jM6Yec5_vqnRimQ.html

@@CompleteCoding Yes That's it! Thank's for Your Help.

I've just looked this up again and you're right!

It's quite hard to demonstrate. One api call just takes 0.3s longer than the second.

Yes, lambdas definitely stay 'awake' for some amount of time. How long varies but is somewhere between 10 and 45 minutes. You can test by calling you lambda (which will cold start), call it again after the first request (warm start - faster response) and then call it 15 minutes later. I might set up a script to do some testing around this.