Posted by David March 12, 2008 @ 07:34 PM
Funny Or Die is pulling high G’s scaling their Rails site to handle 9GBps of video and 20MBps of compressed HTML traffic from the stunts of Will Ferrell and others. Their top video has been seen no less than 50 million times. Rock on, guys.
Ruby on Rails was created by David Heinemeier Hansson, a partner at 37signals,
then extended and improved by a core team of committers and hundreds of open-source contributors.
Rails is released under the MIT license. Ruby under the Ruby License.
"Rails", "Ruby on Rails", and the Rails logo are trademarks of David Heinemeier Hansson. All rights reserved.
|
Sponsored by |
 |
Yeah, scaled using something along the lines of static file caching served up by a high performance webserver like nginx or lightspeed? Yeah, go Rails – what has this got to do with Rails exactly?
Rails didn’t serve that video 50 million times, another product did. Sure, Rails was used to build parts of the site but it’s not the only piece of the infrastructure.
Enough with the confounding marketing hype. :) It’s just as stupid as the people asking the question “Does Rails Scale?”, it’s a stupid question – as you’ve pointed out many times. And this post of yours is just as stupid as their stupid question.
which system are they using? mongrel+apache? postgres or mysql? how many server which how many ram and cpu? and so on :) btw…very good :)
Rails may not have served that video 50 million times (that would be silly) but Rails does count the real-time stats for all of our (Funny or Die’s) views (and votes, etc) in addition to serving all the pages on our site (which are cached using Varnish). Funny or Die isn’t evidence that Rails can serve high-volume video. But it is evidence that a Rails site rich with multi-media can scale big while playing nice with other technologies. The relevant question may not be “Can Rails scale?” but “Does Rails hamper scaling?” – to which the answer, in our experience, is a resounding “No.”
It’s great to see another large site running on Ruby/Rails.
Ryan… some good points, but quit acting like a little !@#$%.
He’s just pointing out that a pretty big (and funny as hell) site is embracing Rails.
Any chance we’ll see a more in-depth article on FunnyOrDie’s infrastructire on http://www.highscalability.com/ ?
@myself:
we’re using 4 varnish boxes proxying to 18 app servers running lightspeed connected to 3 mysql boxes (1 master, 2 slaves) and 2 memcached servers.
Environment is red hat linux for all, 64-bit 4 processor 8gb machines for the dbs and 32-bit dual processor 4gb machines for the web/app servers.
Static files are served off a cdn.
Most days this configuration is way overkill, but we built the site to handle huge traffic spikes, like when we get links on yahoo’s homepage or featured on television we see over 600 page requests per second.
@ryanallensmom point taken, mom :)
@Jon Gubman: that’s some good info – are you serving the videos off the CDN as well? If so, which CDN are you using?
Good idea Dan, when we get a moment we’ll crank out something for http://www.highscalability.com/
Mark Smallcombe VP of Product & Engineering
@ryan: yeah, videos are served off the CDN also. We’re using Limelight.
http://www.scribd.com – much higher traffic and it’s on rails too :-)
Unfortunately, even Rails can’t make Will Ferrell funny.
I used to work with the FOD guys, mostly on the front end of the app. Based on that experience, I’m 100% convinced that for a smart group of developers Rails is a great tool for implementing features rapidly and keeping a manageable codebase while still being able to optimize the bottlenecks.
I have also worked on projects that prove that Rails is no solution to mediocrity, and I think that most kneejerk claims that Rails apps don’t scale come from those working on such projects.
Curious if there have been any problems with Varnish, seems like there had been some segfault problems, but perhaps they were limited to FreeBSD.
Varnish has been working pretty well for us. Its nice and fast and haven’t had any problems with stability.
We were using page caching before – which can be a pain when you have many app servers, plus the other pains with rails’ built in page caching – the way it treats ?params in the uri and doesn’t keep any headers that were with the response – Varnish solved all these.
We’d recommend Varnish over the out of the box rails page caching any day.
”...18 app servers running lightspeed…”
Does this refer to lighttpd or LiteSpeed web server?
It would be interesting to see what web server they are using…
@adam: LiteSpeed
Just a pointer to Multilingual page caching in Ruby on Rails:
http://szeryf.wordpress.com/2008/02/02/multilingual-page-caching-in-ruby-on-rails/