Unacceptably Slow HTTP Round Trips for Rails App

Hi there,

I am testing a Rails 7 application that runs very quickly locally and in my own hosted environments. On Render (especially today) everything is crawling. I wait multiple seconds for dynamic content to load, if it does at all. JS resources often can’t be fetched. Forms take forever to make the roundtrip and load hotwire responses. 502 responses are occasional. And my resources and work is pretty lightweight.

Looking at my metrics, nothing is taxed either on the app or server instances.

Is this a common issue here on Render? It seems silly to scale to multiple instances for a single user, but there are no other levers to pull here. Thoughts?

Thanks. Drew

I took a look at our metrics for the service in your account - it’s bouncing off the memory limit but I wouldn’t expect that to cause it to exhibit what you’re seeing.

It’s tough because the public path seems be a login page - If you get a 502 response then providing us with the ray-ID that should be present along with the x-render-router header value as we can use these to diagnose where the issue lies.

John B

I am seeing something very similar.

For login pages, I am seeing very slow machine behavior (>2 seconds to render a login page, which doesn’t even hit a database). The HTTP round trip is taking ~48 seconds.

What’s up with this?

@evdevdev Your situation appears to be entirely different - you’re using our free plan so your service is going to sleep. The next request will wake it up (you’ll see it as the service starting up in the logs). The speed that it takes to start up a service is VERY dependent on the resultant build size, dependencies etc etc so does vary.

1 Like

And any info on what I’m seeing?

@dbreunig I responded just a bit earlier in the thread

Great. Is there a way to increase memory?

You can change to a higher plan from the service settings page or try and reduce the memory usage (if you’re using Ruby/Puma then reduce the number of workers)

Here’s the request id: Request ID: 7688ec7090ad9459-SJC

Still getting 502

Will try reducing workers.

At such a high “resting usage” there’s just no wiggle room for anything, if there’s no traffic then there’s likely no objects instantiated etc, once you start getting traffic then the app is going to want more resource but there aren’t anything. File uploads etc all need memory so the app is going to want more.

That rayID got a 502 response from us, I’d be super interested in the x-render-routing header if you can get that the next time you see it.

Thanks. I upgraded to 1GB of memory and went from 4 to 2 workers and it’s much more reliable. Thanks for your help.

From a UX perspective, it’s a bit confusing to be adjusting my memory in the subscription tiers not in the ‘scaling’ tab. I get the choice made, but I would have never found how to get more RAM.

1 Like

Great, thanks for the update.

I definitely see what you mean, I’ve raised it with the team - at the very least we could put a pointer on the scaling tab that for vertical scaling you change the service plan,

Thanks for the input!


John B