everything old is new again. this was the concurrency model for pre 2.0 apache. (i think in 2.0 you could pick)
No, what is new here is reforking see https://github.com/Shopify/pitchfork/blob/master/docs/REFORK...
Pitchfork: Rack HTTP server for shared-nothing architecture
51–60 of 71 posts
Re: Pitchfork: Rack HTTP server for shared-nothing architecture
#52For those of you scaling Ruby on Rails: are you more constrained by memory or CPU consumption? 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?
Why chose one over the other? Pitchfork’s selling point is that it allows you to reduce CPU usage with YJIT while still reducing memory usage compared to other servers.
Re: Pitchfork: Rack HTTP server for shared-nothing architecture
#53I'm the author of the original 'refork' feature introduced to Puma a couple years ago [1], that served as an inspiration for this project. As I understand it, Pitchfork is an implementation of a reforking feature on top of Unicorn, a single-threaded multi-process Rack HTTP server. The general idea of 'reforking' is that in addition to pre-forking worker processes at initialization time, you re-fork them on an ongoing…
Hey Will, Pitchfork author here. As mentioned in the Readme, thanks for your Puma PR, it was indeed quite instrumental in Pitchfork inception.
As for why it wasn’t used much as a Puma feature I don’t know, but there are a few challenges with it that prevented me from putting it in production. The most important one being that new workers end up being grand children of the original process, so if the middle process die, you may end up with zombies etc.
It’s also very scary to fork a process that may have live threads currently processing a request. I believe Pitchfork solves most of that.
Re: Pitchfork: Rack HTTP server for shared-nothing architecture
#54Earlier quoted context omitted.
Howdy, I'm on the Shopify team that is working on both pitchfork and a few different performance-improvement projects for Ruby. There's a ton of activity around Ruby performance right now! I think we're entering a period of increased experimentation and rapid evolution as demonstrated by projects like YJIT[1][2], improved inline caching[3][4] and Object Shapes[5] (also used by V8), and variable-width allocation[6][7]…
Could you comment on any projects within Shopify that are helping Ruby's concurrency story? I'm aware of Ractors ( https://docs.ruby-lang.org/en/master/ractor_md.html ) and Fibers, but it's unclear to how feasible these primitives currently are to build the necessary abstractions on top of them that would make Rails more concurrent. https://github.com/socketry/falcon is an interesting project, but again, it's not cle…
To be honest, Shopify isn’t particularly invested in Ruby concurrency.
That’s not really a use case we have, and the community is already investing a lot in that direction (ioquatix with fiber scheduler and ko1 with N:M threads and Ractors)
Re: Pitchfork: Rack HTTP server for shared-nothing architecture
#55I’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. 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. Especially from Microsoft, who has deep compiler/language expertise, and who owns GitHub (large Rail…
> 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. Every place I've worked in the last ~5 years has treated Ruby as "legacy" code for better or worse.
I'm in the ruby world for more than 5 years. there are performance every release.
For the second one, all the code is legacy after some times :)
Re: Pitchfork: Rack HTTP server for shared-nothing architecture
#56Earlier quoted context omitted.
>Especially from Microsoft, who has deep compiler/language expertise, and who owns GitHub (large Rails app). I thought it was missed opportunities those working inside GitHub could not persuade Microsoft to at least budget out additional resources for Ruby. Although they might have their own battle trying to keep everything Rails and not moving to .NET It does worry me a bit that all resources are coming from Shopify…
You are making multiple comments talking about Microsoft and Shopify not putting resources into Ruby/rails but both companies have core contributors on them.
Excuse me?
Where did I said Shopify not putting resources when the last part of my comment was exactly about Shopify putting resources into Ruby Rails.
Microsoft have contribution into Ruby? Or Do you meant Github has Core Contributor in Rails? Name me a single Microsoft employees actively helping in Ruby Core.
Re: Pitchfork: Rack HTTP server for shared-nothing architecture
#57Earlier quoted context omitted.
> significantly-sized companies that ripped Ruby out of everything as they scaled I am assuming Ruby, used here meant Ruby Rails . Or specifically, ripped Rails out of everything as they scaled? The calculus, in many situation would indeed be in flavour of another framework or language in ~2013. The cost of CPU Core has dropped significantly since then, we are not far from having 128 x86 CPU core in a single socket.…
https://shopify.engineering/porting-yjit-ruby-compiler-to-ru... ??
So? What is your point?
Re: Pitchfork: Rack HTTP server for shared-nothing architecture
#58Earlier quoted context omitted.
Which part of raw web performance? These don't seem like web performance benchmarks. IOW I'm not sure how calculating digits of PI impacts serving HTML. Seems like we need benchmarks for actual web workloads. :)
PHP vs Ruby in web benchmark across multiple frameworks (and even no use of a framework) linked below. There’s nearly an entire order of magnitude difference in performance between the best of PHP vs best of Ruby (~400k vs ~50k rps) https://www.techempower.com/benchmarks/#section=data-r21&l=z...
Benchmark is simply incomplete and manipulative.
The "best" doesn't even use an ORM, and it's mostly php anyway. Barely any ruby variants.
Re: Pitchfork: Rack HTTP server for shared-nothing architecture
#59I'm the author of the original 'refork' feature introduced to Puma a couple years ago [1], that served as an inspiration for this project. As I understand it, Pitchfork is an implementation of a reforking feature on top of Unicorn, a single-threaded multi-process Rack HTTP server. The general idea of 'reforking' is that in addition to pre-forking worker processes at initialization time, you re-fork them on an ongoing…
Hey Will, Pitchfork author here. As mentioned in the Readme, thanks for your Puma PR, it was indeed quite instrumental in Pitchfork inception. As for why it wasn’t used much as a Puma feature I don’t know, but there are a few challenges with it that prevented me from putting it in production. The most important one being that new workers end up being grand children of the original process, so if the middle process di…
Isn't HTTP/1.1 transfer encoding chunked a simpler solution to the same problem?
Re: Pitchfork: Rack HTTP server for shared-nothing architecture
#60Earlier quoted context omitted.
Hey Will, Pitchfork author here. As mentioned in the Readme, thanks for your Puma PR, it was indeed quite instrumental in Pitchfork inception. As for why it wasn’t used much as a Puma feature I don’t know, but there are a few challenges with it that prevented me from putting it in production. The most important one being that new workers end up being grand children of the original process, so if the middle process di…
Isn't HTTP/1.1 transfer encoding chunked a simpler solution to the same problem?
Sorry, I see absolutely no relation between the two.