At 1:30 PM PST on 2 March, 2010 we flipped the switch and started serving www.active.com through Akamai. We then watched our average load time and bandwidth consumption stats decrease as the DNS change propogated across the world. The end result has been significant. Below are just some of the improvements we've noticed.
Active.com homepage load time reduced from 6 seconds to less than 1 second
Community homepage load time reduced to an average of 2 seconds
Datacenter bandwidth consumption reduced by at least 30%
Concurrent sessions on our webservers reduced by 45%
The update to active.com last week brought with it a significant improvement in load time and page size. We met last month to determine how we could give the site a bit more zip and came up with a solid list of about 8 items. One of those items, removal of VIEWSTATE, was included in our latest update. VIEWSTATE is a variable used in ASP.NET to make HTTP, a stateless protocol, act like a stateful one. Most of the pages on active.com, however, dont require state, making VIEWSTATE extraneous. And on average VIEWSTATE added an additional 50 to 150 KB to page sizes to the site.
In our latest release we turned VIEWSTATE off. Data shows us that the site is about 23% faster and, with an average page size reduction of 27%, well lower consumed bandwidth out of our production data center by about 500 to 800 GB/month.
results.active.com is our hub for communicating race results to people. We train event timers on how to use the backend portion of the system, and after a given race is completed the timers upload results, making them available to the world at large.
We typically see a lot of traffic on results.active.com after large events, such as the Marine Corps Marathon or the Chicago Marathon. And to be fair, results.active.com hasn't had an exemplary performance record when it comes to handling the volume spikes we get on the Monday after major events.
We've just released a major update to results.active.com adding 3X the scalability we had before. We've also made tweaks to the architecture so that we can add additional servers to the load-balancer should we get any unanticipated increases in volume.
So if you see any issues with site responsiveness please let me know (here on this blog) and I'll look to it personally and immediately.
Predominantly people use our site to find events to participate in. Events like the or the Turkey Trot in Cartersville, GA. We have over 300,000 relevant events in our system. And by relevant I mean things that have recently happened or will be happening in the near future. Past events are archived and are a lot harder to find in our system, but we're working to fix this.
For example, the San Diego Rock 'n' Roll Marathon happens every year. Yet if you search through our system you'll only find next year's event (and possibly last year's). But what did people say about the event in 2004? Was it well run by the event organizer? What was the weather like?
Linking data from past events is one of the projects we're working on in our Directory Initiative. You'll be able to understand what people have said about previous occurrences of an event and can make a better decision about whether or not you'll participate this year.
Oh yeah and we're also working to make our event details pages load faster. Right now we receive a YSlow score of 'F', which we're not proud of. But I can say things are in the works in our prototype environment that will give us a better score. Changes will be rolled out incrementally, as we're touching several areas to "lighten the payload".