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

How Shopify reduced storefront response times with a rewrite

engineering.shopify.com

Post reply on HN
Print view View original

71–76 of 76 posts

Re: How Shopify reduced storefront response times with a rewrite

#71

Post by joelbluminator »

bdibs wrote: post #47

I’m aware that Ruby/Rails isn’t that quick, but it seems mind boggling that an 800ms server response time is considered tolerated, and 200ms is satisfying. I’ve never used Ruby in production so maybe my reference point is off and this is more impressive than I’m giving it credit for.

I'm not sure this has anything to do with Ruby, they're talking about user experience: what's perceptible to humans and what causes frustrations. Also - in most apps db and frontend take way more time than the Rails stack.

Re: How Shopify reduced storefront response times with a rewrite

#72

Post by jashmatthews »

nicoburns wrote: post #70
jashmatthews wrote: post #69

Earlier quoted context omitted.

Right but I'm doing that because those are frameworks in other languages which offer a comparable developer experience. fasthttp isn't even a web framework. It's not surprising that using a raw HTTP library is dramatically faster than using a full framework and ORM but it's also not a sustainable way to build complex web applications with 1000+ developers.

You don't need to have 1000 developers working on the small performance sensitive part of your application though. Split it out into its own application, and then have a small dedicated team. I can't speak to fasthttp as I haven't used Go much, but actix-web in Rust is a full framework (not as full as something like Rails, but certainly more than mature enough to be used for production projects).

I built and maintained a critical production web app using Iron for 3 years. Keeping anything like the performance advantage you see in simple benchmarks in a real app is a big challenge.

Re: How Shopify reduced storefront response times with a rewrite

#73

Post by nicoburns »

jashmatthews wrote: post #72
nicoburns wrote: post #70

Earlier quoted context omitted.

You don't need to have 1000 developers working on the small performance sensitive part of your application though. Split it out into its own application, and then have a small dedicated team. I can't speak to fasthttp as I haven't used Go much, but actix-web in Rust is a full framework (not as full as something like Rails, but certainly more than mature enough to be used for production projects).

I built and maintained a critical production web app using Iron for 3 years. Keeping anything like the performance advantage you see in simple benchmarks in a real app is a big challenge.

Well sure, that's why it only makes sense unless you actually need the performance. But if you do need the performance then implementing it in a language that is designed to enable those optimisations can make a lot more sense than trying to hack around the runtime in a slower language.

Re: How Shopify reduced storefront response times with a rewrite

#74

Post by ksec »

why_only_15 wrote: post #56
pushrax wrote: post #18

Earlier quoted context omitted.

(contributor here) The project does still use code from Rails. Some parts of ActiveSupport in particular are really not worth rewriting, it works fine and has a lot of investment already. The MVC part of Rails is not used for this project, because the storefront of Shopify works in a very different way than a CRUD app, and doesn’t benefit nearly as much. Custom code is a lot smaller and easier to understand and optim…

Out of curiosity, why continue to implement in ruby? If milliseconds are important as you mention, interpreted languages will always be slower.

>I’ll also add that storefront serves a majority of requests made to Shopify but it’s a surprisingly tiny fraction of the actual code.

I am guessing that small pieces of code will the target for TruffleRuby.

Re: How Shopify reduced storefront response times with a rewrite

#75

Post by ksec »

Scarbutt wrote: post #53
bdibs wrote: post #47

I’m aware that Ruby/Rails isn’t that quick, but it seems mind boggling that an 800ms server response time is considered tolerated, and 200ms is satisfying. I’ve never used Ruby in production so maybe my reference point is off and this is more impressive than I’m giving it credit for.

For page reloads, anything below 300ms is fine.

>https://stackexchange.com/performance

Page Rendered in 12.2ms - 18.3ms

Giving plenty of room for Network Latency.

Re: How Shopify reduced storefront response times with a rewrite

#76

Post by joshmn »

pushrax wrote: post #26
joshmn wrote: post #20

Earlier quoted context omitted.

> because the storefront of Shopify works in a very different way than a CRUD app Any interesting/successful patterns you can share/resources you can share on said patterns?

“Not a CRUD app” isn’t a design decision, it’s just that storefront is almost entirely read-only, and the views are merchant-provided Liquid code. Most of a shop's data can be accessed on any page; data dependencies are in large part defined by the view, not the controller.

Oh I Know. As a Rails developer for 10 years, I'm always interested what patterns are developed when straying away from what the original guts of Rails.
Post reply on HN