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

Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

railsatscale.com

Post reply on HN
Print view View original

91–100 of 158 posts

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#91

Post by paulddraper »

mabbo wrote: post #10
sho wrote: post #2

> 1.27 million requests per second > 3TB/minute of traffic "rails doesn't scale"

That's not on a per-host basis. Shopify's design is, quite fortunately, one that partitions really well, as each store is completely independent of each other. Each store can be assigned to one pod, each pod can have as many hosts as it takes to optimize the use of a database instance, and then you can add more pods as the need arises. Edit: to be clear, that's not to say Rails can't scale. It can. It's just that it…

There are of course a lot of things that cross store partitions, e.g. ShopPay.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#92

Post by hu3 »

okeuro49 wrote: post #85

PHP went through some crazy performance improvements from PHP 5.6 to 7.0, in some cases running twice as fast. It's good to see Ruby doing the same. There is something neat about the same code running faster, solely by being on an upgraded platform.

Yep. And PHP is possibly getting an optimizing compiler:

https://www.reddit.com/r/PHP/comments/16hu7dq/php_is_getting...

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#93

Post by reducesuffering »

gloryjulio wrote: post #74
nindalf wrote: post #49

Earlier quoted context omitted.

Yes, not ideal. But we can’t know what would have happened if they had chosen a different language in 2007. Did they have the option of an efficient, well supported language that continues to be used in 2023? Maybe Java, although Java languished for years before development picked up again. C# is also a candidate. But one thing we can’t measure - how many candidates chose to join Shopify and GitHub because they were…

The problem is at the time if you want things done fast, Rails was the right choice. Almost no startup would touch Spring as app server at the time. Django had not reached 1.0 yet, and it's not faster anyway. So for a startup, Rails was the only realistic choices.

What I find ironic was that in 2006, Rails was the shiny new kid on the block. These co's picked the "new" way of doing web dev compared to the stodgy Java/C# types. And yet, by recommending Rails for a new startup in 2023, they're actually more like the stodgy Java/C# old school paradigm camp, that the Rails startups avoided! A startup that would've used Rails in 2006 is more like a startup that is using things like NextJS in 2023. We see that in the stacks of new YC companies

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#94

Post by brianwawok »

phamilton wrote: post #41
mabbo wrote: post #16

Earlier quoted context omitted.

No, they both matter. The database can handle X shops per partition, and the rails host can handle Y shops per partition. If rails were half as fast, you'd need twice as many rails hosts (but no more databases).

> but no more databases Sort of. Twice as many rails hosts means more DB connections which generally means more load/memory on the DB or more load/memory on the external connection pooler. It's only a bit of incremental load, but it's easy to overlook how many other systems need to run to make Rails scale.

No he’s his examples he’s talking 50 stores over 10 machines vs 50 stores over 5 machines. Both would require the same DB count, but the second would save on server costs for stores.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#95

Post by moonchrome »

pjmlp wrote: post #65
moonchrome wrote: post #60

Earlier quoted context omitted.

C# in 2006 was a joke, probably worse than Rails in performance. This was the webforms era and old EF - meant for enterprise customers with a couple of hundred active users max... ASP.NET being a competitive/performant framework is a very recent development (since core basically which became usable past 2.0) Haskell, OCaml and D are niche languages, probably aren't mature enough now to use for a production system tha…

A joke is this comment. All of them were faster and used less resources than a very slow interpreted language, by having JIT and AOT compilers, state of the art GC and great IDE offerings, even the niche ones had better tooling (Leksah and Merlin, versus nothing).

No they weren't - ASP.NET webforms and old EF was such a pile of shit it didn't matter how fast C# was (and back then it really wasn't, granted order of magnitude better than ruby/python, but way behind JVM). The applications built with it were dog slow and buggy - they couldn't even scale in enterprise setting.

Haskell, OCaml, D with great IDE support in 2006 ? Do they have that even today ?

I mean you're suggesting people use C++ for writing web apps (and c++98/03 no less !) - that's got to be facetious.

The real contender back then was PHP and Java, RoR really addressed a lot of issues from both. They both adopted the improvements brought by it since, but it took years.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#96

Post by p8 »

pjmlp wrote: post #89
p8 wrote: post #84

Earlier quoted context omitted.

Nobody cares about performance if you build a business application with a couple of users, a common use-case in 2005. The reason a lot of Java people jumped on the Rails bandwagon, was that an application that would take a month to build in Java with Spring/Hibernate, would take a day in Rails. See also: https://www.oreilly.com/library/view/beyond-java/0596100949/

Some Java people did, there is a reason why Ruby is hardly used outside Rails, while Java rules most of the backend workloads, a mobile OS, and plenty of embedded workloads.

There's also a reason Kotlin has become the language of choice for the Android development industry, Scala became a thing, and ThoughtWorks recommended against using JavaServerFaces.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#97

Post by brianwawok »

tumdum_ wrote: post #78
rapsey wrote: post #58

Earlier quoted context omitted.

It is not 2006 anymore. Rails was a trailblazer. The productivity difference is not as large as it was compared to alternatives.

There are not comparably productive alternatives for rust right now :(

Rust isn’t really a real language for web development though. Just in the bubble here.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#98

Post by mabbo »

brianwawok wrote: post #94
phamilton wrote: post #41

Earlier quoted context omitted.

> but no more databases Sort of. Twice as many rails hosts means more DB connections which generally means more load/memory on the DB or more load/memory on the external connection pooler. It's only a bit of incremental load, but it's easy to overlook how many other systems need to run to make Rails scale.

No he’s his examples he’s talking 50 stores over 10 machines vs 50 stores over 5 machines. Both would require the same DB count, but the second would save on server costs for stores.

I think the above means (if I do get the point) that databases scale in terms of both requests per second and number of active connections.

Having 1000 connections doing 1 request per second isn't the same as having 1 connection doing 1000 requests per second.

But, and I could be wrong, the larger factor is the number of requests per second.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#99

Post by wheels »

berkes wrote: post #50
wheels wrote: post #33

Earlier quoted context omitted.

Am I really going to have to get out the premature optimization quote? Most businesses fail. Those that don't fail, usually don't have interesting scaling issues. (You can go a really long way on a boring monolith stack.) So in most cases, whatever gets things out into the world and able to see if the business can be validated makes sense, and then you optimize later. A nonscalable stack that you can iterate on 50% f…

This hints at a false dichotomy. One that especially Ruby and Rails keep afloat. Productivity and Scalability(in performance sense) aren't opposites. Take Bash. Performs bad and is a guarantee for terrible productivity in a large category of software. But perfect for a niche. Take Java. Performs better than many, and allows for good productivity (if you avoid the enterprise architectures, but that goes for any langua…

It's a false dichotomy in theory. It's mostly not in practice. And that was far truer in 2006 when Shopify got started. Then there really weren't any modern web frameworks in performant languages.

Primarily it's not the language that makes people more or less productive, though it does have some influence. It's mostly the frameworks in those languages. And traditionally the most modern / full-featured web frameworks haven't been in systems languages. The major counterexample at the moment (while still obviously not a systems language) is that modern JS VMs are actually really fast, so while I don't love JS, it does hit that sweet spot at the moment of performance and mature frameworks.

Also, I've never worked in Rust, but am mostly a systems programmer, and while I understand that Rust is supposed to be easier than C or C++, I'm skeptical that it's as easy to work with as higher level languages, or that you could throw most web developers into Rust without some serious additional learning.

Re: Ruby 3.3's YJIT Runs Shopify's Production Code 15% Faster

#100

Post by ericb »

reducesuffering wrote: post #93
gloryjulio wrote: post #74

Earlier quoted context omitted.

The problem is at the time if you want things done fast, Rails was the right choice. Almost no startup would touch Spring as app server at the time. Django had not reached 1.0 yet, and it's not faster anyway. So for a startup, Rails was the only realistic choices.

What I find ironic was that in 2006, Rails was the shiny new kid on the block. These co's picked the "new" way of doing web dev compared to the stodgy Java/C# types. And yet, by recommending Rails for a new startup in 2023, they're actually more like the stodgy Java/C# old school paradigm camp, that the Rails startups avoided! A startup that would've used Rails in 2006 is more like a startup that is using things like…

The NextJS folks and Go folks are in that sweet spot. You use the framework du jour, you pat each other on the back, beaming with the folly of your ancestors to use such inferior tools, thinking "this is a golden age of NextJS (or Go) that will surely never end."

What comes next might not even be better, but that won't matter, because what came before won't be cool anymore.

You die a hero or live long enough to become the villain.

Post reply on HN