Improving Global Web App Performance
The Social Platform, as well as the other MSDN & TechNet apps, is hosted by the Microsoft.com Operations team, with servers in the same data centers that host Live, MSNBC, etc.
I've been fascinated to learn how much application performance varies based on a user's proximity to our data centers. The Social Platform is primarily hosted in the Columbia data center, near Quincy, WA, and a Blue Ridge, VA facility.
As you might expect, performance is really good for users near those data centers. And it's also good in locations that have fat pipes connected back to the areas. For example, perf is great in San Jose and Vancouver, WA.
But until we added CDN support to the Social Platform, performance at more remote locations was poor. For example, our pages were noticably slower to load in the Southern US, and took twice as long to load in parts of of Europe and three times as long in China.
Now that we've added CDN support through Akamai and ChinaCache, performance is stunningly better. Performance is pretty consistent throughout the US and Europe, and while it's still slower in China, it's less than half the time it was before.
By the way, "CDN" stands for Content Delivery Network. The way it works is that we ask the CDNs to cache static resources, such as images and JavaScript files, on servers that are distributed throughout the world. The CDN companies use DNS and routing tricks to serve the cached files from servers that are close to end users.
It turns out that most of the extra time required for a page to load in Europe or Asia is caused by network latency. It can take many tenths of a second, or even several seconds, for a request to make its way over the the network and back from the server. This problem is worse when you're connecting to servers overseas because you have to traverse more nodes on the network.
Another critical factor in page load time is that IE and other browsers only open two connections at a time to any single server. If there are lots of images and scripts on a page, there will be additional network latency for each pair of resources that are requested.
We work around that limitation by hosting the files for any given page on up to five different host names. While the files are physically on the same server, we split URLs across five different hosts to allow parallel loading.
