One last thing I should mention. This doesn't require that your app be ractor safe. The goal is to offload suitable work (just one task for now, I have ideas for at least one more) within the web server itself to ractors, so you can benefit from them without any changes to your app.

5/5

I also need to stop posting stuff like this when it's late for me 😅 I'll come back to answer any questions in the morning. I don't want to divulge too much, especially cause there's a lot more testing I need to do, which could result in major changes before I make it public 🤷🏽‍♂️

4/5

While being inspired by it, I'm making a few design decisions different to Puma that seem to be working out. I won't go into detail yet, but I'll document them eventually. The obvious one is utilising ractors (I'm sure you could guess what for), which Puma should probably also do at some point.

3/5

Soooo many disclaimers:
- not a 1:1 comparison, just as close as I could get it for a benchmark baseline
- not a competition, just showing off an exciting experimental working PoC
- just a micro (but not trivial) benchmark using a toy app
- the RHS isn't 100% rack compliant, maybe 60ish%
- etc.

2/5

Thank you!

Ah it has `#<<`, but hasn't aliased it to `#send`: github.com/eregon/racto...

Also, probably doesn't matter, but it's the other way around in CRuby i.e., `#<<` is the alias.

Has ractor-shim implemented `Ractor::Port#send`? That could be why if not. Ref: docs.ruby-lang.org/en/master/Ra...

github.com/joshuay03/at...

I don't have an answer, but I'm figuring that out myself with what I'm building (not ready to share yet). There's a point where the copying/moving/freezing (i.e., message passing) overhead might outweigh the parallelisation benefits. The answer will vary by the payload and the type of work.

Yes! I missed that. Clearly my Ractor coverage is lacking... @jhawthorn.com has already sent a fix: github.com/joshuay03/at.... I'll get that merged and released soon.

2. The thing that clicked for me was when @jhawthorn.com referred to a ractor as a no-GVL block at Rails World. Rather than chucking a whole Rails app in there, you could find CPU intensive code paths that would choke the GVL, and delegate them to a ractor or few. Think complex parsing of strings.

1. Could you clarify? I'm not aware of Ractors needing a C extension to work. Main limitation: C extension gems must mark themselves Ractor-safe. Shareable requirement on init/send exists, plus new semantics like move (may not last: bsky.app/profile/byro...). Docs: docs.ruby-lang.org/en/master/ra...

Ah that’s unfortunate, that does seem like a tricky edge case… Being able to move in my case seems to be quite a bit more performant than both deeply copying (not surprising), and making shareable and duping just the objects I need to mutate in the receiver. Although, I haven’t properly benchmarked.

Time for a holiday?

Was it the colonoscopy room?

This is from a Datadog APM notebook I used to monitor the impact.

Haha yep, I have to remind myself from time to time as well.

Yes, at the very end of a before_fork—after doing any necessary closing of connections, shutting down threads, etc.

It probably hasn’t been released yet. I would first check if the change has been back-ported to the `8-0-stable` branch, and then whether it was actually included in a release. If not, and it’s already on the branch, it’ll probably be released in a 8.0.x at some point, else 8.1.x.