In the first blog post in this series we talked about differing web acceleration architectures and their performance implications. But there’s a lot more to web site acceleration than just the architecture and its delivery. What about all the other aspects included that are needed to make web site acceleration a complete service, such as:

• How good is their web portal? Do they have good reporting and monitoring?
• Does the Content Delivery Network provider allow you to enter a support ticket in the portal, through e-mail, as well as by calling Customer Support?
• Do they have a global network footprint and if so how dense are their end points?
• What does their SLA look like? Does it guarantee 100% uptime, 95% uptime, or less? Do they offer credits for down time? And are the credits proactive (they tell you when they have downtime and automatically send you a check for the downtime) or are they reactive (the only time they send you a credit is when you notice the downtime and then afterwards notify the CDN and request a credit)?
• How good is their Customer Service organization? Are they 24/6/365? Are their support people very strong? What percentage of issues that come into Support are actually solved by the person who answers the Support call?
• How good is their billing? Do they allow for both Mbps 95th percentile, and GB delivered billing? Do they offer No Commit billing? And do they offer the customer to view their bills online through the Web GUI?
• What do they do about Outages? Are they documented? Will they share them with you? Can you get a report of what corrective action they‘ve taken in order to eliminate their last outages from ever happening again?
• What levels of Redundancy and/or Service Integrity do they deploy? Are all features and functionality redundant and fault tolerant? What about security? Is their infrastructure secure?

These are all important issues and key differences. So let’s talk about details in a couple of areas to underscore the importance of the differences.

Let’s first talk about Reporting. As mentioned above, you’ll need to know things like Cache Miss and Cache Hit ratio to monitor how effective your Content Delivery Network provider is. And there are other critical metrics you’ll need to know as well. If you are deploying a CDN for web site acceleration, be sure that your provider has a good reporting engine.

Customer Service is also a very important issue. If your CDN does it’s job, you should just be able to sign up and then with everything working have little interaction with the provider unless you are implementing new sites or features or functionality. All CDNs have failures - ow they react to them is a key to whether one CDN is better than another. There have been several instances over the years where different CDNs have been down for hours. How CDNs react to network down conditions is a big reason why you’d care about one CDN versus another.

Last but not least there’s network capacity. I know of one story where a CDN won a new customer, put them on the network and that customer not only couldn’t come up on the CDN, but the customer brought the entire CDN down. The CDN could no longer deliver traffic to any of its customers. Network capacity is not somethinig that CDNs like to divulge. How close a CDN is to their network capacity is something that providers like to divulge even less. But it’s important information you need to know if you are a large provider. You’ll need to be sure that you’re content will not bring a CDN provider down.

In summary, web site acceleration is not the easiest CDN service and not all CDNs are the same. Be sure to check out all aspects of web site acceleration before choosing your provider, and don’t assume all CDNs are the same when it comes to Web Site Acceleration.