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

Building and Scaling a Startup on Rails: Things We Learned the Hard Way (by Posterous S08)

axonflux.com

Post reply on HN
Print view View original

21–30 of 56 posts

Re: Building and Scaling a Startup on Rails: Things We Learned the Hard Way (by Posterous S08)

#21

Post by patio11 »

That is a very good article.

I'd suggest absolutely everybody with a web page read up as much as they can about optimizing web page loading. It doesn't matter if you're Posterous or you run your 2,000 daily visitors off a 256 MB VPS which is never under load, optimizing the page can result in 90% decreases in the user-perceptible time it takes to load the page. It doesn't matter if you slave over a hot memcache to save 200 ms off the database queries if your page then takes 7 seconds to render.

Shaving off two seconds, one second, half a second just prints money. Every time I do it I'm flabbergasted by how much it matters.

The HTTP cache control mentioned in the article is one excellent place to start. For the rest, Yahoo pretty much owns this field of research -- any of the presentations from the YSlow folks are worth your time.

http://www.slideshare.net/natekoechley/high-performance-web-...

I'm kind of a lightbox junkie and I've had some good results recently by the simple expedient of having the browser preload the image (e.g. ) prior to the actual user interaction which calls it to display. There are a billion similar site-specific tricks you can do in Javascript these days.

Re: Building and Scaling a Startup on Rails: Things We Learned the Hard Way (by Posterous S08)

#22

Post by teej »

cperciva wrote: post #11

Sad town happens. 1 in 4 requests after Request A will go to port 8000, and all of those requests will wait in line as that mongrel chugs away at the slow request... I don't use Rails, or even Ruby at all if I can avoid it, so I'm sure I'm missing something obvious here, but... why in the world would anyone want to use a web server which can only handle one request at once?

Mongrel is multithreaded, solid, and fast, the issue was with, which Rails wasn't thread-safe until a little while ago.

Re: Building and Scaling a Startup on Rails: Things We Learned the Hard Way (by Posterous S08)

#24

Post by jerf »

tptacek wrote: post #13
cperciva wrote: post #11

Sad town happens. 1 in 4 requests after Request A will go to port 8000, and all of those requests will wait in line as that mongrel chugs away at the slow request... I don't use Rails, or even Ruby at all if I can avoid it, so I'm sure I'm missing something obvious here, but... why in the world would anyone want to use a web server which can only handle one request at once?

Sorry, what's the platonic ideal you're suggesting as an alternative? There are threaded Ruby web servers, but, just like with Python, the interpreter is mostly giantlocked. The overwhelming majority of web apps out there are running under Apache, which just like Mongrel is preforking and queueing, not running everything simultaneously.

"Sorry, what's the platonic ideal you're suggesting as an alternative?"

Something like Yaws, built in Erlang. With fine-grain threading that works well, you don't get the one-to-one OS process to task mapping.

But that certainly comes with its own set of tradeoffs. There are some workloads where that can be a massive win, but committing to any of the currently still-obscure languages/runtimes that can pull this off with panache means you're committing to a less-well-developed library environment.

Facebook chat runs on Erlang for a reason... and the rest of Facebook runs on PHP, also for a reason.

Re: Building and Scaling a Startup on Rails: Things We Learned the Hard Way (by Posterous S08)

#25

Post by rantfoil »

laktek wrote: post #23

Great article! BTW, I was wondering what are the testing strategies used and how did you guys ensured smooth integration of features?

Rspec, Cucumber, Integrity, and a custom end-to-end testing process that runs using the daemons gem that assures all critical aspects of the site runs at all times.

Re: Building and Scaling a Startup on Rails: Things We Learned the Hard Way (by Posterous S08)

#26

Post by patio11 »

patio11 wrote: post #21

That is a very good article. I'd suggest absolutely everybody with a web page read up as much as they can about optimizing web page loading. It doesn't matter if you're Posterous or you run your 2,000 daily visitors off a 256 MB VPS which is never under load, optimizing the page can result in 90% decreases in the user-perceptible time it takes to load the page. It doesn't matter if you slave over a hot memcache to sa…

Oh, one more link while I'm at it:

http://www.slideshare.net/stoyan/high-performance-web-pages-...

The presentation I cited in the parent is more motivational and less stuffed with "Here is a checklist of actionable steps that if you implement will make you more money for each one you do."

Re: Building and Scaling a Startup on Rails: Things We Learned the Hard Way (by Posterous S08)

#27

Post by smokinn »

tptacek wrote: post #4

Great article. Background/deferred job processing has been immensely painful for us, and I have no idea what the accepted best job queue is. We're still stuck on backgroundrb, which is a nightmare. Nanite looks like overkill, and has too many deps.

We simply use an in-memory queue. Beanstalkd has worked quite well for us. (Not a rails app though)

Re: Building and Scaling a Startup on Rails: Things We Learned the Hard Way (by Posterous S08)

#28

Post by drusenko »

teej wrote: post #18

> You're only as fast as your slowest query.... Use HAProxy. Take the time to configure it correctly. It's absolutely the most stable and useful loadbalancer I've used. It also solves this issue by talking to your backends.

I would highly recommend keepalived, which is well-written software for managing ipvs, a load balancer in the Linux kernel. Very, very fast, flexible, and extremely reliable.

EDIT: ipvs/keepalived only operate at layer 3, which is one reason why they are so fast. if you need layer 7 stuff, this won't do it.

Re: Building and Scaling a Startup on Rails: Things We Learned the Hard Way (by Posterous S08)

#29

Post by Freaky »

cperciva wrote: post #11

Sad town happens. 1 in 4 requests after Request A will go to port 8000, and all of those requests will wait in line as that mongrel chugs away at the slow request... I don't use Rails, or even Ruby at all if I can avoid it, so I'm sure I'm missing something obvious here, but... why in the world would anyone want to use a web server which can only handle one request at once?

It's not the webserver, it's Rails; prior to 2.2 it used a Big Giant Lock around the dispatcher, so it would serialize requests.

Of course, even without that Ruby itself will only use a single CPU, since the interpreter itself has a Big Giant Lock, but it can still use threads to multiplex requests and avoid wasting time waiting on every IO.

JRuby allows for proper concurrent multithreaded request handling; I'm surprised it's not a more popular deployment option.

Post reply on HN