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

31–40 of 76 posts

Re: How Shopify reduced storefront response times with a rewrite

#31

Post by balfirevic »

tehlike wrote: post #25
balfirevic wrote: post #23

Earlier quoted context omitted.

Didn't NHibernate have the cartesian product problem solved in a neat way by having various fetch strategies? You could specify to eagerly load some collections and have NHibernate issue additional select statement to load the children, producing maximum of 2-3 queries (depending on the eager-loading depth) but avoiding both N+1 problem and cartesian row explosion problem.

yes, that's the common method, but you still end up issuing multiple network calls. The problem wit issuing select statements to load the children is you have to wait on the first query (root) to finish so you can issue others which adds to the network latency (usually low, but it also depends). It's still not as good as having materialized viewmodels on server where you can issue a single query to get everything you…

I went and looked at the docs to refresh my memory - there was also a subquery fetch strategy where you didn't have to wait for the root entity to load, but that comes at the expense of searching through data twice - which might or might not be worth it, depending on how complicated the query is.

I do wish relational databases (PostgreSQL and SQL Server specifically, since I work with those) had better support for automatically updated real-time materialized views.

Anyway, thanks for working on NHibernate - I miss some of it's configurability and advanced capabilities.

Re: How Shopify reduced storefront response times with a rewrite

#32

Post by cbothner »

pqdbr wrote: post #17
pqdbr wrote: post #12

Some of the listed optimizations were: > We carefully vet what we eager-load depending on the type of request and we optimize towards reducing instances of N+1 queries. > Reducing Memory Allocations > Implementing Efficient Caching Layers All of those steps seem pretty standard ways of optimizing a Rails application. I wished the article made it clearer why they decided to pursue such a complex route (the whole custo…

Someone replied but deleted right when I was posting this answer, so I'm replying to myself: What I didn't understand was why the listed performance optimizations couldn't be implemented in the monolith itself and ensued the development of a new application, which is still Ruby. In a production env, the request reaches the Rails controller pretty fast. I know for a fact that the view layer (.html.erb) can be a little…

Don't forget that a Shopify store is 100% customizable by merchants using Liquid (Turing complete, not that you should try). There is no .html.erb layer. Think of Storefront Renderer as a Liquid interpreter using optimized presenters for the business models.

Re: How Shopify reduced storefront response times with a rewrite

#33

Post by lazyant »

I didn't care especially for the technical details, what I like about this article is that the first thing they mention is the success criteria of the project (hopefully it was done at the very beginning, before any implementation). Then on top of that, they created an automated tool to verify such criteria automatically and objectively.

This is a great approach and unfortunately I don't think many (most?) software projects start out like that.

Not defining conditions of victory and scope creep are possibly the biggest risks in software projects.

Re: How Shopify reduced storefront response times with a rewrite

#34

Post by catsarebetter »

cutler wrote: post #8
bsaul wrote: post #3

Earlier quoted context omitted.

That’s also my question after reading this post. When trying to shave off milliseconds by going for a full rewrite, moving away from ruby seems like an obvious decision...at least intuitively..

Their monolith was written in Rails so Ruby alone was not the source of slow performance. In fact the solution was more to do with cloning the database in order to be able to isolate reads and writes so not even a programming language problem at all.

No way they're still doing monoliths? Is there a blog post on that?

Re: How Shopify reduced storefront response times with a rewrite

#36

Post by tehlike »

balfirevic wrote: post #31
tehlike wrote: post #25

Earlier quoted context omitted.

yes, that's the common method, but you still end up issuing multiple network calls. The problem wit issuing select statements to load the children is you have to wait on the first query (root) to finish so you can issue others which adds to the network latency (usually low, but it also depends). It's still not as good as having materialized viewmodels on server where you can issue a single query to get everything you…

I went and looked at the docs to refresh my memory - there was also a subquery fetch strategy where you didn't have to wait for the root entity to load, but that comes at the expense of searching through data twice - which might or might not be worth it, depending on how complicated the query is. I do wish relational databases (PostgreSQL and SQL Server specifically, since I work with those) had better support for au…

Automatically updated materialized views are something I really want too.

Take a look at ravendb, it might be a good thing to try on next smallish project that you can move to a later one :)

Postgres has a nice advantage of supporting json, so in theory you could have embedded documents as materialized views and whatnot, but it's hard to make it play nice with orms.

Re: How Shopify reduced storefront response times with a rewrite

#38

Post by jacques_chester »

balfirevic wrote: post #31
tehlike wrote: post #25

Earlier quoted context omitted.

yes, that's the common method, but you still end up issuing multiple network calls. The problem wit issuing select statements to load the children is you have to wait on the first query (root) to finish so you can issue others which adds to the network latency (usually low, but it also depends). It's still not as good as having materialized viewmodels on server where you can issue a single query to get everything you…

I went and looked at the docs to refresh my memory - there was also a subquery fetch strategy where you didn't have to wait for the root entity to load, but that comes at the expense of searching through data twice - which might or might not be worth it, depending on how complicated the query is. I do wish relational databases (PostgreSQL and SQL Server specifically, since I work with those) had better support for au…

> I do wish relational databases (PostgreSQL and SQL Server specifically, since I work with those) had better support for automatically updated real-time materialized views.

I've been keeping an eye on these folks: https://materialize.io/

Re: How Shopify reduced storefront response times with a rewrite

#39

Post by thejacenxpress »

Unfortunately they are still highly dependent on other APIs.

When San Diego Comiccon went live on funko.com (shopify) the website was fine but the checkout was bottlenecked by the API calls to shipping providers. Many never were able to checkout and Funko had to issue an apology.

Unfortunate that no matter how great you can improve your own product you may still be dependent upon others.

Re: How Shopify reduced storefront response times with a rewrite

#40

Post by bdibs »

aloukissas wrote: post #37

Naive question: the "storefront" piece seems like it's a static page. Why does it need SSR? Even so, it could be SSR'ed to static _once_ (kind of how NextJS does this from 9.3+), then have it served by CDN/edge. I'm probably missing something here.

They mentioned caching full HTML responses so I'm guessing that's what they're doing.
Post reply on HN