Pitchfork: Rack HTTP server for shared-nothing architecture
1–10 of 71 posts
Re: Pitchfork: Rack HTTP server for shared-nothing architecture
#2How does it compare to puma?
Re: Pitchfork: Rack HTTP server for shared-nothing architecture
#3Looks very promising!
Re: Pitchfork: Rack HTTP server for shared-nothing architecture
#4I’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 Rails app).
Re: Pitchfork: Rack HTTP server for shared-nothing architecture
#5From r/ruby (including discussion from author): https://old.reddit.com/r/ruby/comments/xwcvty/a_new_web_serv...
Re: Pitchfork: Rack HTTP server for shared-nothing architecture
#6everything old is new again.
this was the concurrency model for pre 2.0 apache. (i think in 2.0 you could pick)
Re: Pitchfork: Rack HTTP server for shared-nothing architecture
#7How does it compare to puma?
From the Reddit thread linked above (lots of context there, worth reading), the author answers:
> what's the main benefit?
Drastically reduced memory usage by improving Copy-on-Write performance. For mid-sized apps it can even use less memory than puma depending on how you set it up. See this synthetic benchmark.
> Why did you decide to build reforking into a fork of Unicorn instead of contributing it to Puma?
Mostly for simplicity. You can build this in Puma, but there are a few extra challenges. For instance you don't want to refork when another thread is currently processing a request, you'd risk leaving some global resource in a corrupted state. So you'd first need to stop accepting traffic and wait for all requests to complete. The problem is, Puma doesn't have a request timeout, so if the request never complete, what do you do? Lots of small challenges like that. But I think it would be awesome if Puma was to take back that idea. Puma's fork_worker feature was a big part of the inspiration after all, and I'd even be happy to help Nate or someone else do it.
Re: Pitchfork: Rack HTTP server for shared-nothing architecture
#8I’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…
Not following what you mean. This server is from a shopify employer (major enough?). This server makes quite impressive improvements in terms of memory usage. Moreover, shopify is contributing a production grade JIT to the CRuby runtime.
Re: Pitchfork: Rack HTTP server for shared-nothing architecture
#9I’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…
There have been plenty of major performance improvements for Ruby but most of them require changes that just aren't feasible for a large codebase. For example, there are alternative Ruby interpreters that are far faster than the MRI but they're not usually a drop in replacement because they don't have full Gem or really general ecosystem compatibility.
Also, some performance improvements like JIT just don't matter that much for Rails because the primary problem isn't single thread performance it's the lack of cheap parallelism.
Re: Pitchfork: Rack HTTP server for shared-nothing architecture
#10everything old is new again. this was the concurrency model for pre 2.0 apache. (i think in 2.0 you could pick)
That was only forking the apache process. This is forking the whole ruby app that also happens to speak HTTP. The gain is in the app side not in the best way to serve HTTP where this is probably a loss over threading or event based solutions.