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

Poor Man's Scalability

codypowell.com

Post reply on HN
Print view View original

11–20 of 63 posts

Re: Poor Man's Scalability

#11

Post by eytan »

Your story closely resembles the challenges we had scaling sommelierwine.ca before a media event at our latest launch location. I knew that our site would receive an increase in traffic, and the increase would only be temporary.

As a rails site hosted on Heroku, this gave us the ability to scale our site using the gambit of widgets that Heroku offers; but, we didn’t want to spend the money and cheat ourselves from the satisfaction of scaling our site.

Using New Relic (a gem available on Heroku) I identified our first performance bottleneck - database queries. Certain queries were taking over 30 seconds to complete! These database queries all involved a table of BLOBs (on the order of 20MB) that needed to be searched and sorted. I tried adding indexes but that only marginally reduced the query time. The solution we found included moving the BLOBs to their own table while keeping an index to them in a table of their attributes [1]. Doing this, we were able to reduce query times down to less than a 100ms.

The remaining bottlenecks we found using YSlow has helped us reduce the overhead in loading pages substantially.

Even though we were able to weather the storm of visitors to our site, we did leave some tasks for the next one including implementing caching, background processing, and remote file storage. All in time.

Does anyone have other wallet-friendly Rails/Heroku scaling stories share?

[1] This is database 101 stuff - a class I never took.

Re: Poor Man's Scalability

#12

Post by jibs »

Because i'm in a particularly pedantic mood: I don't think ELB (Amazon's load balancing) is free, which is a little misleading.

In fact:

* $0.025 per Elastic Load Balancer-hour (or partial hour)

* $0.008 per GB of data processed by an Elastic Load Balancer

Source: http://aws.amazon.com/ec2/pricing/

Obviously these are problems loads of people face / hope to face, so it would have been nice to get some more 'meat' in this post.

Edit: formatting

Re: Poor Man's Scalability

#13

Post by dasil003 »

swombat wrote: post #9
eropple wrote: post #5

Earlier quoted context omitted.

Indices on a database aren't "premature optimization". They're part of understanding your data model, how it will be requested, and--more in a SQL database than a MonogDB database, but still--constraints on the data stored in your database. Claiming basic development practices to be "premature optimization" is a fantastic way to paint yourself into a corner because of stupid decisions in your haste to "get it out the…

I consider Indices to be premature optimisation. Moreover, they're very low level, potentially dangerous premature optimisation. Imho, they should be the very last trick you use to optimise. First, you try and figure out if you can reduce the number of repeated queries. Then you try and figure out if you can get rid of chunks of code that spawn lots of queries altogether, by tweaking the algorithm to do things differ…

No, caching should be the last trick you use to optimize.

Indices are standard way to achieve basic performance levels of a database. They may have their downsides but "potentially dangerous" is dramatically overstating the case. Furthermore, the dangers of premature optimization are about taking extra time or adding complexity to something that ultimately doesn't matter, not about using very basic features in a sane way.

The correct optimizations to make first are ones that make the biggest impact percentage-wise as well as being the most elegant in the code. Indices typically fit both categories very well. Unless you are doing a lot of stupid things, there's not going to be much lower-hanging fruit, but even if there is, after you apply sane indices that will be when your profiling will start to reveal the real interesting possibilities for optimization. The idea that indices are a good final optimization does not show much interest in real performance.

Re: Poor Man's Scalability

#15

Post by dasil003 »

troels wrote: post #10

It's fairly basic stuff this, but important none the less. Kudos for recommending Yslow (or PageSpeed) - it's indeed brilliant. You didn't mention much about http caching, which I think is probably as important as the other things you mentioned; Not only does it improve performance for the user, but it also reduces load on your server and it enables you to put up an edge side cache for extra performance. As for the p…

> Btw. 1.5s to render the front page? That's way beyond acceptable, in my book. But I suppose it depends a bit on what the web site does.

Agreed. This will have an extremely negative impact on your user engagement. Now if this is measuring end user response time rather than server-side page generation it might not be quite so bad, but generally I think most common pages should target < 150ms.

Re: Poor Man's Scalability

#16

Post by RobPfeifer »

Cody, just one note on your website - I couldn't tell at all what Famigo offers without clicking on something. Instead of having "Famigo helps families find and manage mobile games and apps" in a hover-over pop-up, have a similar tagline somewhere people can see easily.

Re: Poor Man's Scalability

#17

Post by nostrademons »

eropple wrote: post #5
eric-hu wrote: post #4

Earlier quoted context omitted.

I'm very very reluctant to call those mistakes. From the author: > I didn't get too upset here; I expected us to do poorly. After all, we'd spent all of our development time in actually building something people want, not on scaling up for thousands of imaginary users. Perhaps it would be relevant to the conversation if the author could chime in with how many projects or ideas they went through that failed. Perhaps t…

Indices on a database aren't "premature optimization". They're part of understanding your data model, how it will be requested, and--more in a SQL database than a MonogDB database, but still--constraints on the data stored in your database. Claiming basic development practices to be "premature optimization" is a fantastic way to paint yourself into a corner because of stupid decisions in your haste to "get it out the…

It's not hard to apply an index after the fact. You don't paint yourself into a corner by leaving them off initially.

And very often, you can't understand your data model and how it will be requested until you've actually built an app and gathered some data. Users will surprise you, and do things you never expected, and probably render 80% of your app (oftentimes, the 80% you worked hardest on) obsolete immediately.

Re: Poor Man's Scalability

#18

Post by StavrosK »

dchest wrote: post #7
bmelton wrote: post #3

With the rise of cloud services, and their relative inability to serve naked domains, there are a couple of easy fixes for this. The first is to create a vhost in your webserver that serves an index.htm page on your NON-www url. The contents of that page would simply redirect users to the www.yourdomain url. If that seems like too much work, an even easier fix (truncated for brevity) is to do something like this: var…

Why not plain old HTTP 301/302 redirect?

Please, please use a redirect. The GP's suggestion is not something you want to do.

Even better, just use http://wwwizer.com/ (look for the free redirect service banner on top).

Re: Poor Man's Scalability

#19

Post by StavrosK »

jibs wrote: post #12

Because i'm in a particularly pedantic mood: I don't think ELB (Amazon's load balancing) is free, which is a little misleading. In fact: * $0.025 per Elastic Load Balancer-hour (or partial hour) * $0.008 per GB of data processed by an Elastic Load Balancer Source: http://aws.amazon.com/ec2/pricing/ Obviously these are problems loads of people face / hope to face, so it would have been nice to get some more 'meat' in…

Neither is a second EC2 instance, or were they running that already? Was it just not running a web server?

Re: Poor Man's Scalability

#20

Post by St-Clock »

swombat wrote: post #9
eropple wrote: post #5

Earlier quoted context omitted.

Indices on a database aren't "premature optimization". They're part of understanding your data model, how it will be requested, and--more in a SQL database than a MonogDB database, but still--constraints on the data stored in your database. Claiming basic development practices to be "premature optimization" is a fantastic way to paint yourself into a corner because of stupid decisions in your haste to "get it out the…

I consider Indices to be premature optimisation. Moreover, they're very low level, potentially dangerous premature optimisation. Imho, they should be the very last trick you use to optimise. First, you try and figure out if you can reduce the number of repeated queries. Then you try and figure out if you can get rid of chunks of code that spawn lots of queries altogether, by tweaking the algorithm to do things differ…

I agree with you, but he was using MongoDB and AFAIK, indexing is a must with this kind of db. Actually, I hope that he does not expect a big write load because he seemed to have added the indexes pretty quickly without thinking too much about it...

Just to reiterate, with a RDBMS with a decent query planner, indexing early is premature optimisation.

Post reply on HN