Skip navigation

NEED HELP?|

Active Product Development

4 Posts tagged with the speed tag

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

performance-active.com-home.gif

Community homepage load time reduced to an average of 2 seconds

performance-community-home.gif

Datacenter bandwidth consumption reduced by at least 30%

mbits-per-second.gif

Concurrent sessions on our webservers reduced by 45%

concurrent-sessions.gif

 

There's still room for improvement with our load time averages.  Apache Bench tests show HTML-only load times for the active.com homepage to be under 100 milliseconds.  The program that generated the chart above also downloads CSS, Javascript and 3rd party collateral.  Regardless, we're excited about this change.

2,561 Views 1 Comments Permalink Tags: active.com, speed, improvements, akamai

Adding a Little Zip

Posted by JeremyGThomas Jul 6, 2009

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, don’t 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%, we’ll lower consumed bandwidth out of our production data center by about 500 to 800 GB/month.

 

Here’s a summary of performance improvement:

 

Homepage

Average Page Size: 17% reduction

Page Load Time: 18% faster

 

Event Details

Average Page Size: 38% reduction

Page Load Time: 26% faster

 

Channels (Running used as the control)

Average Page Size: 21% reduction

Page Load Time: 24% faster

 

Articles

Average Page Size: 32% reduction

Page Load Time: 27% faster

 

Moral of the story - turn off VIEWSTATE whenever and wherever you can.

1,897 Views 2 Comments Permalink Tags: active, speed, product_development, improvements

Scaling results.active.com

Posted by JeremyGThomas Nov 10, 2008

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.

1,744 Views 1 Comments Permalink Tags: development, speed, results, scalability

Linking Events

Posted by JeremyGThomas Oct 28, 2008

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".

1,574 Views 2 Comments Permalink Tags: development, speed, product_development, event_details