Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pitchfork: Rack HTTP server for shared-nothing architecture

github.com

Post reply on HN
Print view View original

21–30 of 71 posts

Re: Pitchfork: Rack HTTP server for shared-nothing architecture

#21

Post by pedrocr »

jaxrtech wrote: post #15
skrtskrt wrote: post #11

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/whateve…

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…

There are some tools specific to some transformations at least:

https://c2rust.com/

Re: Pitchfork: Rack HTTP server for shared-nothing architecture

#22

Post by a-dub »

pedrocr wrote: post #10
a-dub wrote: post #6

everything 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.

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?

Re: Pitchfork: Rack HTTP server for shared-nothing architecture

#23

Post by dgl »

jaxrtech wrote: post #15
skrtskrt wrote: post #11

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/whateve…

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…

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.

Re: Pitchfork: Rack HTTP server for shared-nothing architecture

#24

Post by treeman79 »

compumike wrote: post #19

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?

Database locks is usual issue. Avoidable if planned better.

Memory is second. In 15 years CPU has never been a real concern.

Re: Pitchfork: Rack HTTP server for shared-nothing architecture

#25

Post by bradgessler »

flavorjones wrote: post #12
tiffanyh wrote: post #4

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 Rail…

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 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.

Re: Pitchfork: Rack HTTP server for shared-nothing architecture

#26

Post by dan_quixote »

tiffanyh wrote: post #4

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 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.

Re: Pitchfork: Rack HTTP server for shared-nothing architecture

#28

Post by pedrocr »

a-dub wrote: post #22
pedrocr wrote: post #10

Earlier quoted context omitted.

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.

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 pro…

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.

Re: Pitchfork: Rack HTTP server for shared-nothing architecture

#29

Post by Puts »

treeman79 wrote: post #24
compumike wrote: post #19

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?

Database locks is usual issue. Avoidable if planned better. Memory is second. In 15 years CPU has never been a real concern.

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.

Re: Pitchfork: Rack HTTP server for shared-nothing architecture

#30

Post by tiffanyh »

tenderlove wrote: post #20
tiffanyh wrote: post #13

Earlier quoted context omitted.

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.

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...

Post reply on HN