[HN Gopher] Pitchfork: Rack HTTP server for shared-nothing archi...
___________________________________________________________________
Pitchfork: Rack HTTP server for shared-nothing architecture
Author : bkudria
Score : 88 points
Date : 2022-10-12 18:25 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jbverschoor wrote:
| How does it compare to puma?
| aeontech wrote:
| 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.
| joshmn wrote:
| From r/ruby (including discussion from author):
| https://old.reddit.com/r/ruby/comments/xwcvty/a_new_web_serv...
| tomcam wrote:
| What is Rack? Hard to search for
| gurchik wrote:
| https://github.com/rack/rack
| tomcam wrote:
| Thank you!
| [deleted]
| a-dub wrote:
| everything old is new again.
|
| this was the concurrency model for pre 2.0 apache. (i think in
| 2.0 you could pick)
| pedrocr wrote:
| 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.
| a-dub wrote:
| many serious applications back then built by developers who
| cared about performance and latency made use of mod_perl. it
| put the entire perl interpreter (which then loaded perl
| modules that defined the application) into the preforked
| apache httpd processes.
|
| often times you'd put a proxy in front, serving static assets
| with a lighter weight http so that slow loads wouldn't tax
| limited server capacity for big httpd processes that included
| full perl interpreters and all application code loaded.
|
| so it seems it's almost exactly the same?
| pedrocr wrote:
| It's very similar to that setup. I don't think that was
| particularly common though and probably the reason prefork
| went away. Particularly as apache and later nginx were used
| as the user facing webservers proxying to something else
| inside (first with fastcgi and latter just http). The
| preforking advantage then moved to that server inside which
| is what this is. Nginx or something similar will still be
| running in front of this with a threading or event model
| instead of forking. So this is not going back to an old
| idea as it never really left, it just left apache because
| no one ran it as an application server and there are better
| ways to run an http frontend. Preforking is also not what's
| new here, this is just an optimization over the preforking
| model in unicorn which is over a decade old.
| skrtskrt wrote:
| 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.
|
| I wonder what that financial calculus looks like between these
| options for a large organization:
|
| 1. trying to basically reinvent the workings of an entire
| programming language and migrate your Ruby apps to these new
| tools/runtimes/typecheckers/whatever
|
| 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.
| tiffanyh wrote:
| Probably not a financial decision.
|
| Tobias (Founder/CEO) was an early Rails core contributor. So
| Ruby on Rails is in Shopify DNA.
| jaxrtech wrote:
| A lot of the time, I ask myself, "why don't we seem to have a
| tool with robust source-to-source transformation?" You could
| call it "cross-language refactoring". I wouldn't be surprised
| if someone with the code-base the size of Google has some
| internal tool. Maybe this is just wishful thinking. The closest
| thing I've seen is in academic research, e.g. [1].
|
| [1]: Koppel, Solar-Lezama - Incremental parametric syntax for
| multi-language transformation (2017) -
| https://dl.acm.org/doi/10.1145/3135932.3135940
| dgl wrote:
| I mean Google did essentially do this:
| https://opensource.googleblog.com/2017/01/grumpy-go-
| running-...
|
| Except without actually solving the problem of making the
| translation nice and readable. But this kind of thing at
| least gives you options for changing language.
| pedrocr wrote:
| There are some tools specific to some transformations at
| least:
|
| https://c2rust.com/
| compumike wrote:
| For 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?
| treeman79 wrote:
| Database locks is usual issue. Avoidable if planned better.
|
| Memory is second. In 15 years CPU has never been a real
| concern.
| Puts wrote:
| Second this. After spending several years of full time just
| troubleshooting others web apps I can say that not only are
| database locks in 99.99% of the cases the real bottleneck but
| also that developers in general are quite bad at managing
| databases and will try to micro optimizing just about
| anything before looking at their DB queries.
| aeontech wrote:
| Looks very promising!
| tiffanyh wrote:
| 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.
|
| 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).
| sosodev wrote:
| 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.
| flavorjones wrote:
| 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], and
| smaller improvements like better constant invalidation[8].
| Significant investments in TruffleRuby[9] are still going on by
| Oracle, Shopify, and other companies.
|
| And recently, Takashi Kokubun gave a talk at Ruby Kaigi about
| the future of JIT compilers in Ruby that gives a peek at a
| whole new set of optimizations Ruby can work on (as well as
| some performance comparisons against other interpreted
| languages)[10]. You may be surprised to see how well Ruby (with
| the JIT enabled) performs compared to Python 3.
|
| All of which is to say, I think there's quite a bit of
| performance improvement being made in recent Rubies, and that
| trend will likely continue for quite some time.
|
| _update_ And I forgot to mention that some very notable
| computer science researchers and their teams are working in the
| Ruby community now![11]
|
| [1]: https://news.ycombinator.com/item?id=28938446) [2]:
| https://speed.yjit.org/ [3]: https://bugs.ruby-
| lang.org/issues/18943 [4]: https://bugs.ruby-
| lang.org/issues/18875 [5]: https://bugs.ruby-
| lang.org/issues/18776 [6]: https://bugs.ruby-
| lang.org/issues/18045 [7]: https://bugs.ruby-
| lang.org/issues/18634 [8]: https://bugs.ruby-
| lang.org/issues/18589 [9]:
| https://eregon.me/blog/2022/01/06/benchmarking-cruby-mjit-yj...
| [10]: https://speakerdeck.com/k0kubun/rubykaigi-2022 [11]:
| https://shopify.engineering/shopify-ruby-at-scale-research-i...
| bradgessler wrote:
| 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 clear how difficult it would be deploying
| a Rails app on top of this. My experience with these
| concurrency models in Rails apps is that one single gem could
| make a blocking IO call (for example) and negate all of the
| concurrency/performance gains. It would be cool if Ruby could
| be configured to throw errors for these types of calls to
| make finding and fixing offending gems easier.
|
| There's a lot of really great projects happening and plenty
| to be hopeful about, but when that stuff will land or the
| changes the rest of the community and ecosystem should think
| about making still isn't clear.
| tiffanyh wrote:
| Do you think Ruby will ever be able to catch up to PHP in raw
| web performance? If so, when (months/years)?
|
| https://benchmarksgame-
| team.pages.debian.net/benchmarksgame/...
|
| Please don't take my comments as unappreciation for the hard
| work going into Ruby.
| tenderlove wrote:
| 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. :)
| tiffanyh wrote:
| 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...
| dan_quixote wrote:
| > 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.
| chucke wrote:
| 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.
___________________________________________________________________
(page generated 2022-10-12 23:00 UTC)