I'm the author of the original 'refork' feature introduced to Puma a couple years ago [1], that served as an inspiration for this project.<p>As I understand it, Pitchfork is an implementation of a reforking feature on top of Unicorn, a single-threaded multi-process Rack HTTP server.<p>The general idea of 'reforking' is that in addition to pre-forking worker processes at initialization time, you re-fork them on an ongoing basis, in order to optimize copy-on-write efficiency across processes, especially for memory allocations that might happen after initialization. The Pitchfork author mentions sharing YJIT machine code as a particularly important use-case [2], one that has become relevant in recent Ruby releases.<p>I never saw much interest in the concept when I originally introduced the reforking feature to Puma, and it remained a kind of interesting experiment that never saw much production uptake. I'm thrilled that Shopify is iterating on the concept through this project and I hope the technique will continue to be refined and developed, and see broader adoption as a result.<p>[1] <a href="https://github.com/puma/puma/pull/2099" rel="nofollow">https://github.com/puma/puma/pull/2099</a> ; <a href="https://github.com/puma/puma/blob/master/5.0-Upgrade.md#fork_worker" rel="nofollow">https://github.com/puma/puma/blob/master/5.0-Upgrade.md#fork...</a><p>[2] <a href="https://github.com/Shopify/pitchfork/pull/1#issuecomment-1251944727" rel="nofollow">https://github.com/Shopify/pitchfork/pull/1#issuecomment-125...</a>
I have now worked at several significantly-sized companies that ripped Ruby out of everything as they scaled, usually replaced with Go, though none as large as Shopify.<p>I wonder what that financial calculus looks like between these options for a large organization:<p>1. trying to basically reinvent the workings of an entire programming language and migrate your Ruby apps to these new tools/runtimes/typecheckers/whatever<p>2. incrementally rewriting critical paths to something more performant (Go/Rust) & just throwing more servers at the Ruby stuff you haven't managed to replace yet.
From r/ruby (including discussion from author): <a href="https://old.reddit.com/r/ruby/comments/xwcvty/a_new_web_server_github_shopifypitchfork/" rel="nofollow">https://old.reddit.com/r/ruby/comments/xwcvty/a_new_web_serv...</a>
I’m still surprised that we haven’t seen much larger improvements in Ruby performance over the last decade given the large number of major tech companies using Rails.<p>Yes, I'm aware of 3x3 but for the most common usage of Ruby which if for Rails apps - there hasn't been anything like the gains PHP saw from 5.x to 7.x.<p>Especially from Microsoft, who has deep compiler/language expertise, and who owns GitHub (large Rails app).
I wonder how this will handle Websockets. With Rails and Hotwire Turbo, the story to support sprinkling in Websockets for broadcasting events is there. Puma can handle long running connections which makes it suitable to use for that (reverse proxied by nginx of course). Would Unicorn and Pitchfork work the same here in that as long as it's reverse proxied by nginx it'll be fine for Websockets, even with thousands of open connections? What about in development where you wouldn't likely have nginx in front of your app?
That's a great project, very interested to see how it plays out. In my previous job we used Unicorn but didn't hit any GVL contention issues (much smaller scale than Shopify's).<p>As a suggestion to the authors: A section titled "Why not Unicorn?" explaining the rationale behind this and why one would want to choose it over Unicorn, would be very helpful. If not in the current experimental stage, then in the "stable" one.
For those of you scaling Ruby on Rails: are you more constrained by memory or CPU consumption?<p>If you could choose a 50% reduction in process memory footprint, versus a 50% reduction in CPU cycles to serve your average request, which would you pick?