[yalooze]

I’m using Cloud Run too and love it in principle and, mostly, in practice. I’m running a Rails app which takes about 30 seconds to start on Run (much quicker on a standard instance or local and I’m not sure why). My other gripe is that it will just randomly restart (not after being idle for some time but literally as I’m clicking around the website). There are no server errors and nothing I can see in the logs. Coupled with the fact that restarts take around 30 seconds it makes for quite a poor initial experience for my web users.

[kelseyhightower]

Cold starts can be one of the biggest trade offs when adopting a Serverless platform like Cloud Run, especially with 30 second start up times. We introduced minimum instances[1], currently in beta, which will allow you to specify a minimum number of container instances to be kept warm and ready to serve requests.

There is a cost for doing so as instances kept running in this way do incur billing costs [1].

I've done some work with Ruby in the past, and based on my experience, you might not be able to take advantage of Cloud Run's best feature, concurrency[2], which is another way to reduce cold starts by routing concurrent requests to the same container instance. Ruby maybe blocking in flight requests and forcing us to fire up another instance to handle it. Once the first request has completed there is a chance the container instance processing that request will be spun down, this is something minimum instances can help with. You might need more than one minimum instance to compensate for the lack of concurrency if you really want to see improvement in overall latency.

[1] https://cloud.google.com/run/docs/configuring/min-instances

[2] https://cloud.google.com/run/docs/about-concurrency

[Just1689]

This advice might not be at all helpful, but anyway.

Consider checking the following: - Number of CPUs. The number of CPUs is not CPU cores but Kubernetes millicores. 1 vCPU on CR = 400m (4/10 of a CPU core). - Background processes - not recommended [https://stackoverflow.com/questions/61154349/google-cloud-ru...] - Container size on disk. Google Cloud is fast. However they need to cap the moving container images around as they can't use all the network capacity for moving a 400MB Docker image. If you're not already, use multi-stage builds with tiny final images.

[kircr]

Where do you get the info that 1 vCPU on CR = 400m? I would have expected 1 vCPU on CR = 1000m

[nikon]

This is not correct.

> Limits and requests for CPU resources are measured in cpu units. One cpu, in Kubernetes, is equivalent to 1 vCPU/Core for cloud providers and 1 hyperthread on bare-metal Intel processors.

[tlarkworthy]

Yeah I have a jvm jboss type thing that take 5 mins to startup, which is why I have that pubsub to self in the proxy so I can absorb delays in a managed queue. This of course relies on the upstream not being time sensative or needing a syncronous reply. However, nginx does start in 400ms on cloud run so it's clearly it's the cruft in the docker that's doing it and not the hosting

(code is here BTW https://github.com/futurice/terraform-examples/tree/master/g...)

[spyspy]

For comparison I’ve been using Go and a distroless container image and never had any problems.

However you can set the minimum instance count now. That feature was opened up for Cloud Run managed a few weeks ago.