Site: FunAdvice.com Date submitted: 11/28/2007

Funadvice.com is a social network centered around advice between its members. The site has seen consistent high growth and now boasts well over a million unique visitors every month.

The site has been running on this kind of hardware and software stack for the past 6 months:

• 4 Core Intel Woodcrest
• 4 Gigs of Ram
• Rails 1.2.3
• Postgresql Database
• Apache 2.2.3
• Mongrel 1.0.x

Our main problem domain was in 2 areas, RAM and keeping our Mongrels Alive. With the mongrel containers, our rails instances would easily consume up to 600 MB of RAM without a thought. If left unchecked, our pack of 5 mongrels would begin to swap the machine.

We used monit to contain the resources of the mongrels. Monit would restart a mongrel container if it grew to more than 160MB, or consumed more than a certain amount of CPU resources. The problem was that we could not dynamically adjust to more or less traffic by automatically increasing (or decreasing) the number of mongrels controlled by monit. Additionally, sometimes monit would not reliably restart mongrels, because of mongrel PID issue handling.

Apache also does not intelligently send requests to mongrels based on load or other issues. The whole stack was a constant headache to watch and keep running. It was a pain to sometimes wake up and see that there was only a single (or sometimes no) mongrels running. There had to be a better way.

Two months ago at a recent Miami Ruby Users Group, a member mentioned Litespeed and the fact that with it, he could sleep at nights not worrying about the deployment stack.

We decided to give it a shot and that very same night installed a test version. Based on our online research and testing we purchased the Enterprice 4 CPU license in a week and migrated the site to it. Migration consisted of installing Litespeed, setting up the main domain, our country domains and our asset domains (images.funadvice.com, static.funadvice.com). Nothing needed to be changed in the application itself. Migration worked perfectly and we were up and running.

First thing we noticed was that the memory usage for the RailsRunner.rb process was never exceeding 140MB, which was great. Litespeed also dynamically increased or decreased this amount of runner processes for us. Typical server latancy for a static page dropped to an average 180 milliseconds from around 280 milliseconds.

The best thing about the whole experience was that I did not have to worry at the peak times of 11am to 6pm. Even if we were swamped with requests and the server load went way up, we are confident that litespeed will adjust. We're consistently adjusting and tuning various server parameters.

Since the switch to Litespeed, we've grown 42% in traffic. A nice side effect of all of this is that because the pages are faster to load, we get spidered by Google faster, and we get ranked higher in the search engines. Our users are also happier. The next move is to setup a cluster of web servers and separate the database server. We look forward to trying out the Litespeed cluster product!

Author: Ericson Smith (co-founder Funadvice.com)

URL: http://www.funadvice.com

Inception: March 2003