All systems ready for launch…

A couple nights ago, I did a dry-run of a single server deployment of KitchenPC onto the Rackspace cloud.  The main purpose was to figure out what kinds of issues I’d run into during the actual deployment, but I also took this opportunity to test the performance of Rackspace’s “CloudServers” product and see how the site “felt” on this platform.

Getting the site up and running on a Windows 2008 RC2 64-bit instance was pretty easy, although I ran into some hassles with the new version of IIS and trying to figure out where all the settings were.  The site felt amazingly fast, any page would just “appear” instantly.  The meal planner code was also quite fast, at least the same speed as the Dell PowerEdge server in which KitchenPC called home during the alpha.

I spent a bit of time writing some scripted tests using jMeter.  These tests were pretty basic.  I ran jMeter on a separate machine on the Rackspace cloud, as not to degrade the web server performance.  I decided to run the tests within the cloud (as opposed to a remote location) since the goal is to test the actual server performance, and not Rackspace’s network capabilities (I already assume they have obscene amounts of network bandwidth.)

A single test would perform an HTTP GET and download the Login page, then POST the Login page back creating a new user account with a random email and password.  It would then follow the 302 redirect to the homepage, thus creating a user context.  At this point, it would issue AJAX calls to do the following:

• Load five random recipes
• Load the first and second pages of the news feed (similar to the Facebook wall)
• Perform a search query with some hard coded parameters

Next, it would issue HTTP GET commands for the following:

• Cookbook.html (A version of the search results page that returns everything in the user’s cookbook)
• MealPlan.html (the page that allows the user to enter meal planner criteria)
• Calendar.html (The user’s calendar)
• Profile.html (The user’s account settings page)
• Home.html (Back home again, figured it’d be nice to load this twice since it will be so common)
• Search.html (Advanced recipe search page)
• Pantry.html (The user’s pantry)

I then add a recipe to the shopping list, add a recipe to the cookbook, and manipulate the calendar a bit.  I then create a new recipe with a couple basic ingredients and a random title.  Lastly, I update the user’s account by changing a single setting.

I figure this is a decent simulation of a single user messing around with the site for a bit, and at least touches the main features.  I decided not to test the meal planner, because I already know that’s not gonna hold up too well under heavy server loads :)

I decided to simulate 100 users simultaneously running the above script, each running said steps 5 times in a row.  This would last several minutes, which would allow me to watch the CPU usage for both IIS and Postgres.

Also, while the test was running, I logged on with my own web browser from my own Internet connection to see how the site “felt”.

Perf Testing Results (Click to see full size)

The results were extremely satisfying.  Out of the nearly 14,000 HTTP requests, there were zero errors and the average response time was around 2.3 seconds.  The total server CPU usage was pegged at 100% the entire time (which is what you’d want, as every server resource should be used to respond to requests as fast as possible) and IIS took about 60-70% of the CPU while Postgres idled along at around 10-20%.  IIS used around 110 megs of RAM, and Postgres never allocated more than 10 megs (I assume it just had my entire DB cached in memory the whole time.)

I poked around the site on my home computer from remote, and the site still felt nice and quick, even with 100 simulated users doing all sorts of stuff.  Now, I’m not really sure I could come up with an accurate estimate of how many “user accounts” a single server instance could handle, but if 1 out of 1,000 users were logged in at any one time, then this means a single instance should be able to handle 100,000 user accounts.

Oh, one more thing to point out.  I did not test loading static content such as image files as they’ll be loaded from a CDN and also usually cached after the user logs on anyway.

Not counting bandwidth, running a Windows 2008 server instance with a gig of RAM costs about $60/mon from Rackspace.

After all is said, I don’t see any major show stopping issues in terms of performance.  Well, unless 100 people want to use the meal planner all at once.  I do have some ideas on how to improve that scenario though.

Next, on to release!