Over the last several months we’ve been taking a hard look at performance and have been optimizing pages/actions that take longer than usual. What do we define as usual? We’ve set a benchmark of 500 milliseconds for server processing time as our high watermark. Anything over that and we try to take a look at to see what we can do. There are some actions that are process intensive and others that depend on third parties but for the most part we should be able bring all actions down to below 500 milliseconds, ideally to around 100 – 200 milliseconds. In December we started recording how long server actions were taking in our database (these are requests for actual data, not images, CSS, or javascript). We then started improving performance for important and/or sluggish actions. One of the first we tackled was “My Cellar”:
Month Avg. (milliseconds)
December 2008 864
January 2009 765
February 2009 653
As you can see we’ve made a 20% improvement but we’re still not under the ideal benchmark of 500 milliseconds, so there’s more work to do. Also in January we installed a distributed cache for our domain objects which had the effect of reducing performance a bit. The big benefit, however, is that we now have the ability to scale by adding any number of virtual machines.
We also have made great strides on the CSS and Javascript front as well. In early February we started time stamping links to CSS and Javascript. Now those files have very long expires times and the timestamp only changes when the content inside the file changes. This results in fewer requests from your browser to our servers which improves performance (pages load much faster).
Our engineers having been reading posts on www.highscalability.com about how sites like Flickr, Facebook, Twitter handle scale and we’ve been applying some of the techniques with pretty good success. Stay tuned for more updates on performance improvements.
