7:58 this is not true, even if you have a reserved capacity for a function, it can still scale. Throttling will happen when you hit the maximum concurrency of your account or if you set a concurrency limit on individual AWS Lambda functions.
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.
Do you see a benefit of combining multiple functions into a single lambda to reduce cold starts. For example if a know web page might make 3 calls at load it might get 3 cold starts, If those 3 function we in a single lambda which could parse the request then there would be only 1 cold start.
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.
Great video..i have been struggling with this provlem since a month..our lambda is in vpc as well and with 1024 ram it gets a cold starts around 5-6 sec..dont know how it can be improved..the second invocations is arround 600-700ms..The lambda is of an enterprise api so its code size is also arround 5-6mb..can u suggest me some solution. PS- the keep alive period is now 5-6mins in AWS
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.
Hi ! i'm new in AWS Lambda, right now i try to develop a function API geteway, SO I want to create function call every 5 minutes a Sage 100 API and send directly to my database (CMS Directus) without Getway API url, so I know how the retrieved data from the Sage API but I am can't send the data(from Sage 100 API) without going to the Geteway API. I thank you
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. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-VhhFkNYCmZ0.html
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.
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
Nice video! But I think demonstrations with some images would have been more helpful rather than you talking to the camera. Maybe even showing live examples of what you are explaining would be even better.
