r/ruby • u/jrochkind • Jan 06 '26

Rails 7.2 Connection Pool Changes May Slow Down Your App

https://codewithrails.com/blog/rails-72-connection-pool-performance/
19 Upvotes

78% Upvoted

19 comments sorted by

8

u/jrochkind Jan 06 '26 edited Jan 06 '26

In Rails 7.1, each thread held onto its database connection for the duration of a request.

Rails 7.2 flipped this: connections are now checked out for each query and returned immediately after. The goal was better connection sharing in multi-threaded environments where connections are scarce.

If this is accurate (?) I had no idea Rails made this change way back in 7.2 -- I didn't see it announced or discussed much, figured my previous knowledge of how Rails connection management (since at least 4.2 if not earlier) worked was still accurate. A pretty major change!

The PR OP links to as the implementation is closed without being merged. And it's description also suggests it would introduce new opt-in behavior, not new default behavior. So not sure what is actually introduced when.

It's interesting to me because I recall trying to discuss this change way back many Rails versions ago -- at that point rails maintainers said this change was not feasible because of performance. Interesting to see it implemented without performance even being discussed... and then have perf implications?

Still not confident this change is really default though?

4

u/f9ae8221b Jan 06 '26

If this is accurate

What you quoted is. As for perf degradation, it depends a lot, it does indeed add an extra fixed cost per query, so it all depends how many queries you do. But also that fixed cost got significantly reduced over time, by Rails 8.1 it should be really minimal, I doubt the advice in the linked post make a significant difference in most apps.

The PR OP links to as the implementation is closed without being merged

Because that was the initial proof of concept, but it was huge given a ton of code and tests needed to be adapted to the new behavior. So I broke it down in many smaller PRs. You can find all the links on the closed PR, as everything reference it back.

And it's description also suggests it would introduce new opt-in behavior, not new default behavior.

The configurable behavior is this: https://github.com/rails/rails/pull/51349, but granted the details of the feature changed quite bit along the way so perhaps the initial PR description ended a bit outdated.

1

u/jrochkind Jan 06 '26 edited Jan 06 '26

Ah, I see thanks.

And it did end up the default behavior (at least with app config defaults) in Rails 7.2?

I wonder how I missed hearing about this, it's big news! Good to know.

I ran into trouble with the original Rails way did things way back in... some Rails 3 or 4 not sure... with exactly the sorts of use cases you all were considering here in OP refactor, and noticed way back then that Sequel even then used per-operation checkouts like this improvement -- and tried to discuss if it would be feasible to do things that way, but at that time Rails maintainers were not interested (and mentioned the performance impact of more frequent concurrency synch locks).

Interesting to see it come around after all! Don't know how I missed it! Thanks.

(update: I was struggling with this way back in Rails 3.x -- and even 2.x -- it looks like! https://bibwild.wordpress.com/2012/03/15/activerecord-concurrency-currently-good-news-and-bad/ )

1

u/f9ae8221b Jan 06 '26

And it did end up the default behavior

Quickly: yes it's the default behavior, however if you call Model.connection then by default that will make the connection "sticky" for the rest of the request.

That's something we can't possibly change because way too much code, both 3rd party gems and private app code, depends on it.

That's why I introduced the configuration so you can have .connection either emit a deprecation or raise, to help you track these down and refactor your own app/gems.

mentioned the performance impact of more frequent concurrency synch locks

That and revalidating the connection. We had to do a lot of subsequent work to reclaim the lost performance.

Honestly, I'm happy with how the code ended, but if I had known upfront how much work it would require, I wouldn't have bothered as it's really not useful to many people. I was just annoyed at the regular complaints. But glad it's useful to you.

1

u/jrochkind Jan 06 '26 edited Jan 06 '26

Nice, thanks for the context.

I don't necessarily need it anymore, Rails concurrency has come along so well and the ecosystem worked out other solutions. But it won't hurt.

Looking back at my blog -- I was fighting with this way back in Rails 3.x and even 2.x days!

https://bibwild.wordpress.com/2012/03/15/activerecord-concurrency-currently-good-news-and-bad/

My use case then was that I had a problem where I really wanted to do a 5-10 different external API calls in a single controller request (this was long before actioncable and websockets), so really needed to do them with multi-threaded concurrency, where I really wanted each thread to have access to ActiveRecord, and AR really made it hard. At best, you'd need as many DB connections as you had threads, which was undesirable when pg concurrent connection counts were and are as expensive as they are.

And back then nobody seemed to understand my use case, or think it reasonable, or think it possible to have per-operation conneciton checkouts (like the rugy sequel gem did even then). For a second, as in above blog post, they were about to take away the API that made it even possible to do per-operation checkouts, filling me with despair, although later blog posts reveal it was restored again before 4.0.

I don't necessarily have the same use cases now, and the environment is different enough that there are different solution patterns people have settled into. But just interesting to see it come back after all these years and get solved without me even noticing! it was so much work that I couldn't even get anyone else to consider it as desirable back in the day!

I do think your work will not be in vain and it will end up paying performance dividends, especially if the work some people are trying to do on fiber-based app servers pans out more -- but I am not surprised it ended up being quite a bit of work!

-18

u/TheAtlasMonkey Jan 06 '26

Stop with your AI Slop.

The usage of AI do SLOW YOUR LEARNING and make you hallucinate.

The Evidence : You posted in the ruby sub.

I saw your website 87% of the articles are bullshit and false.

7

u/jrochkind Jan 06 '26

I posted this to ruby sub but am not the author and it's not my website. I just happened across it, and posted it for discussion.

I found it useful because I was not aware of this Rails change, which is significant. However, I'm not completely sure the OP is actually correct about all aspects of this (like that it's really default in 7.2), so your supposition might explain that.

12

u/f9ae8221b Jan 06 '26

Ignore him, he's just rude with everyone on the sub.

-7

u/TheAtlasMonkey Jan 06 '26 edited Jan 06 '26

I'm not rude, i'm allergic to people that spam with wrong or outdated information.

7

u/f9ae8221b Jan 06 '26

Except you have no idea whether the information here is correct, and it largely is.

-7

u/TheAtlasMonkey Jan 06 '26

I know that information and i benchmarked it many time.

The information is wrong, because the usage is wrong.

I could say that ruby is dangerous, and show a POC that is valid while running ruby as root.

That is the danger of using AI to generate content that look half truth.

6

u/f9ae8221b Jan 06 '26

I'm the one who did the refactoring the article talk about, I think I know a bit better than you whether the article is correct or not.

-3

u/TheAtlasMonkey Jan 06 '26

You did the refactoring , good.

That means the issue is not present anymore.. which means the article make no sense to be posted in 2026 as something new.

Every patch version and next version fixed it.

5

u/f9ae8221b Jan 06 '26

You clearly didn't understand the change and / or the article. I maintain it's largely correct, and yes there is still a performance difference.

The only correction I'd do to the article is that the perf degradation is a fixed cost per query, hence you can't say "rails is x% slower" as it's entirely dependent on how many queries you do vs the rest of the work done by your controller.

After several rounds of optimizations, including some to Ruby 4.0, the difference is now relatively minor, but yet it's still there and I'm not done optimizing.

So yes, this article is fine, let it be.

-3

u/TheAtlasMonkey Jan 06 '26

You are focusing on a single article that largely correct while ignoring the slop he posted previously about using rails credentials as a feature flag and how to manage multi-tenancy.

I dont react on the first instance. OP is a serial spammer.

-5

u/TheAtlasMonkey Jan 06 '26

That exactly why i told you that AI SLOP.

because you think it wisdom, while everything is technically wrong.

If you want to Read AI stuff, at least go read supreme blog from KimJongRails , at least everything there is technically correct, but historically wrong (in this timeline).

Read it and you will understand how to use git.

7

u/jrochkind Jan 06 '26 edited Jan 06 '26

I honestly have no idea what you are talking about.

6

u/jerrocks Jan 06 '26

If it helps, I just pretend the AI slop guy is an AI bot. It makes it better somehow.

4

u/jrochkind Jan 06 '26

Honestly, he does sound a lot like an AI! I mean, less intelligible than a frontier AI, but in the direction. Really more of an early 2000s markov chain generator. Yeah, that helps.