I did some sort of rubber duck blogging about a patch I'm currently working on: https://byroot.github.io/ruby/performance/2025/04/26/unlocking-ractors-object-id.html
Rails core, Ruby committer, Senior Staff Engineer on Shopify's Ruby and Rails infrastructure team.
I did some sort of rubber duck blogging about a patch I'm currently working on: https://byroot.github.io/ruby/performance/2025/04/26/unlocking-ractors-object-id.html
@stevenharman @floehopper 2.2.0 is out.
Thanks for helping fixing the CI.
I tried to dig into the test suite issue a while ago, but didn't find the issue after a few hours: https://github.com/rails/activerecord-session_store/pull/213#issuecomment-2497462780
If someone can figure it out I'll merge the fix and cut a release.
Some personal thoughts on the usability of MySQL and PostgreSQL protocols:
https://byroot.github.io/performance/2025/03/21/database-protocols.html
Here we go. That one I really needed to get off my chest for the better part of a year, so I feel relieved now.
It's really long but hopefully not too hard to follow.
https://byroot.github.io/ruby/performance/2025/03/04/the-pitchfork-story.html
@kmcphillips Thanks!
This is the last subject I wanted to talk about before I can start talking about Pitchfork itself.
What I think Ractors are useful for, and why that isn't writing web servers:
https://byroot.github.io/ruby/performance/2025/02/27/whats-the-deal-with-ractors.html
@soaproot it all depends on what your threat model is.
But even if encryption within the datacenter is mandated, HTTP2 or even HTTPS isn't the only way to achieve it.
Continuing my series to give context on Pitchfork design, why I think HTTP2 support isn't important (for a Ruby application server).
https://byroot.github.io/ruby/performance/2025/02/24/http2-past-the-load-balancer.html
One more entry in my series to give context to Pitchfork design.
https://byroot.github.io/ruby/performance/2025/02/09/guard-rails-are-not-code-smells.html
I wrote down my personal thoughts on whether it's worth removing Ruby's GVL and what it would take.
I wanted to talk about Ractors too, but this is already too long, so that's for another time.
https://byroot.github.io/ruby/performance/2025/01/29/so-you-want-to-remove-the-gvl.html
Before I can talk about Pitchfork, I obviously have to talk about fork.
If you ever did some system programming you likely won't learn much though.
https://byroot.github.io/ruby/performance/2025/01/25/why-does-everyone-hate-fork.html
@nateberkopec @getajobmike that's nice to hear, especially since gvl_timing probably has a bigger overhead than gvltools, because it does one subscription per thread rather than a single one.
> 1-5% overhead on a saturated multi-threaded process
To be entirely honest with you, this was from a very quick and dirty benchmark, I don't really have a proper figure.
I mostly meant to warn that it adds some overhead whenever the active thread switch, so depending on how fast this happens, it may impact perf.
But YMMV, best to benchmark yourself.
@kerrick it's kinda my point that these aren't easy PRs because optimizing further without breaking compatibilty is non-trivial or impossible.
One example of that is the ActiveRecord::Attribute API, e.g. https://github.com/rails/rails/pull/53331
I only managed to make small gains to it.
@Schneems for the 50%, if you aren't doing significantly more IO than that, then you'll experience significant GVL contention if you're trying to use a threaded server, hurting your service latency.
As for the 95%, this one is more handwavy, but it is to say that until a dozen or so Ruby threads, using an async based system is unlikely to yield much benefits in term of throughput.
I want to write a post about Pitchfork, but before I can get to that I need to share some thoughts.
I suspect this one may be more controversial than the optimizing JSON series 😅.
https://byroot.github.io/ruby/performance/2025/01/23/the-mythical-io-bound-rails-app.html
It is done, I finally concluded the ruby/json optimization series.
I hope you enjoyed it: https://byroot.github.io/ruby/json/2025/01/14/optimizing-ruby-json-part-7.html
Here's most of the parsing optimization covered, only one extra part and the series should be over. But I have ideas of further topics.
https://byroot.github.io/ruby/json/2025/01/12/optimizing-ruby-json-part-6.html
Part 5 is out, I'm finally done with the encoding side, so next time I can start talking about parsing:
https://byroot.github.io/ruby/json/2025/01/04/optimizing-ruby-json-part-5.html