3 ms·
This solves one part of the cold start problem. Starting the container and loading the image on to it is still going to cause some latency.
by ajoy 7y ago
This solves one part of the cold start problem. Starting the container and loading the image on to it is still going to cause some latency.
- nostrebored 7y agoSolves might be strong, but it removes a big portion of the cold start latency that was difficult to optimize for and out of the control of developers. Creating minimal images isn't difficult for a number of environments (e.g. webpacking your node.js lambdas) and barring necessarily large images (think pandas on Lambda) this puts a lot of control for the cold start p99 back in the hands of customers. Overall, definitely a big win!
- StreamBright 7y agoWhich can be mitigated by invoking your own Lambda functions once every minute or 5 minutes. Usually does not blow the budget.
- nostrebored 7y agoWarming functions in the previous VPC architecture was always a questionable practice. You had no guarantee that your environments would be warm across all subnets or which subnets would handle incoming requests. Beyond that, what happens to requests which you receive when the function is being warmed? You still incur cold starts. There has never been a guarantee of environment reuse. Any architecture which isn't capable of incurring cold starts is not a good fit for serverless.
- scarface74 7y agoWhich is a horrible idea.... How many lambdas do you keep warm? 5, 10, 20? Every new connection is a new lambda instance. You're still just delaying the inevitable. Just use Fargate if you want to stay serverless and don't want the cold start times -- well at least before today.
- StreamBright 7y agoSorry but it does not matter how many since everything is automated and you create the warm up scheduler when you create the function. As other pointed out in this thread that are other challenges with this approach. >> Just use Fargate We were trying to and we decided that is not our cup of tea. Lambdas are.
- scarface74 7y agoYes it does matter. In your scheduler, how do you ensure your ping (the way you start an instance) is actually creating another instance to keep warm or reusing another instance? If you want to always keep 20 instances warm, you have to keep the first ping active until the 20th one is done. In other words, if you want to keep 20 active instances warm and you send 20 requests in 5 seconds, if each request only takes .25 seconds. You will only have 5 warm lambdas. The 6th real concurrent connection will still have a cold start. Also while you are pinging the request to keep it warm, that instance can serve a real user. Also, API Gateway has an algorithm to decide whether to launch a new lambda are cache a request hoping that using an already warm lambda will free up.
- k__ 7y agoI found it a bit strange that they sold Lambda as THE new way to do API development. You can connect API-Gateway with other services via Velocity templates, which don't have cold starts. AppSync also doesn't suffer from cold starts. Both are also serverless services. Lambda is good if the other solutions are missing something, so you can drop it in quickly, but I wouldn't use it as the go to services for that...
- Scarbutt 7y agoAPI-Gateway can return HTML?
- k__ 7y agoSure. You can write Velocity templates for integration responses. Normally they are JSON because that's what all the AWS services return and API-Gateway just passes them along. But you could write something like this: #set($pets = $input.path('$')) <html lang="en"> <head> <meta charset="utf-8"> <title>Pets</title> </head> <body> <table> <th>ID</th> <th>Type</th> <th>Price</th> #foreach($pet in $pets) <tr> <td>$pet.id</td> <td>$pet.type</td> <td>$pet.price</td> </tr> #end </table> </body> </html>