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

21–30 of 63 posts

Re: Poor Man's Scalability

#21

Post by lowglow »

dasil003 wrote: post #15
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.

So what would you both consider "the next steps" in page speed optimizations?

Re: Poor Man's Scalability

#22

Post by driverdan »

troels wrote: post #8
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…

Indexes can most certainly be premature optimisation. There's a cost associated with an index.

The cost increases significantly by doing it later on. Indexing when you have little data is easy. Indexing on a live site with millions of rows and lots of users can be much harder.

Re: Poor Man's Scalability

#23

Post by grk »

eytan wrote: post #11

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

For the new cedar stack, make sure you serve static assets from some sort of CDN, as each static file served ties up one of your dynos. With Rails 3.1, setting up cloudfront takes about 5 minutes and it's relatively cheap.

Re: Poor Man's Scalability

#25

Post by jibs »

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…

ooh, this looks really problematic on multiple levels (why wait for JS etc).

A simple solution, which I've used--and I think the OPs situation is similar--is to just have an additional A-record pointed to the ELB, this should work unless the OP is doing something really fancy. No need for route-53, even go-daddy will let you do this.

However, route-53 gives you much better TTL, so if you ever need to re-route..

Re: Poor Man's Scalability

#26

Post by sciurus »

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…

A more efficient and search-engine friendly approach is to perform a 301 redirect. For a single site, in Apache this would look like

    RewriteEngine On
    RewriteCond %{HTTP_HOST} ^example\.com [NC]
    RewriteRule ^(.*)$ http://www.example.com/$1 [R=301,L]

Re: Poor Man's Scalability

#27

Post by troels »

lowglow wrote: post #21
dasil003 wrote: post #15

Earlier quoted context omitted.

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

So what would you both consider "the next steps" in page speed optimizations?

Make sure that http cacheability is good (send proper http headers, e-tag and expires; serve assets from cookie-less sub-domain). But if the page renders in 1.5 secs, I would try to address that also. That's highly specific to the application and its technical platform, so I couldn't really say how to approach that - But break out a profiler and go for the big chunks for a start.

Re: Poor Man's Scalability

#28

Post by codypo »

CoffeeDregs wrote: post #2

Thanks to the author for taking time to write up his experience. That said, this is really basic stuff. How in the world could a home/index page have so many queries that it took 9 seconds? Oh, no indices... Then how could you have built a DB-backed web app and not considered indexing? A better title for the post might be "Scaling Mistakes I Made While Building Our Website and How I Fixed Them".

Oops, I think I didn't express myself very clearly. When I was sending 20 requests a sec in a load test, the average response time for all the requests was 9 seconds. In a normal case, the page was loading in a fraction of that.

Also, we didn't lack all indexes, just a couple of important ones. We've been iterating quickly on the site and we weren't analyzing the performance as our queries were refactored.

Re: Poor Man's Scalability

#29

Post by codypo »

MichaelApproved wrote: post #14

This seems like basic stuff. I'm more interested in the story about how you got this to the top of the front page. Edit: Less obnoxious.

Blackmail. I have pics of pg and Steve Ballmer sharing an ice cream cone, and I'll make them public unless I get the proper upvotes.

I actually don't know what happened here either. I was at a kid's birthday party, and I look on Twitter to see one of my cofounders had submitted this and that it was shooting up the front page.

Re: Poor Man's Scalability

#30

Post by codypo »

RobPfeifer wrote: post #16

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.

Thanks for pointing this out. We JUST pushed a change this week where we removed a huge banner saying "We help families find and manage blahblahblah" and replaced it with a few other things. Maybe we need to revert that!
Post reply on HN