Too slow even with provisioned provisioned concurrency

[hopewise]

Too slow even with provisioned provisioned concurrency

[metaskills]

Cool, let me know what you find out with the cold starts and how your workloads might differ from the assessment in the guides. We can always amend them with other's knowledge and use cases.

[metaskills]

Have you read this guide? https://lamby.custominktech.com/docs/cold-starts?

At a minimal, your Rails Lambda should be at 1792 which is 1vCPU. I'd be curious to hear why you need provisioned concurrency too. Lots of details please.

[metaskills]

FYI, I just transferred the docs site to lamby.cloud. So that link above might have been broken for a few hours. Should be working now with redirects.

[hopewise]

Thanks @metaskills , that was useful to point out, I have set memory to 1792, much faster, but still can be faster if I use the right web server, currently, I am using Puma as the web server, built for parallelism, but it will not useful to use in AWS Lambda.

I will try to remove Puma and totally depend on Bootsnap

[metaskills]

but still can be faster if I use the right web server

Can you explain that? There is no web server... your application should be glued at the Rack (app) layer.

currently, I am using Puma as the web server

Wait what? No no no... no web server is needed... especially parallelism... Lambda does not work that way. Lamby should be hitting your app directly via Rack... remember... a Rails application is a Rack application. API Gateway sends events directly to it with Lamby. In fact, I'm not even sure how you would use a web server. But that's the point, you do not need one. Can you talk a little about that?

depend on Bootsnap

[hopewise]

Thanks for explaining, as I have already deployed my Rails app to an EC2 cluster, I was relying on a web server, I just forgot that I will not needed it on Lambda as being a Rack application.