Evaluating few CDN options
June 11th, 2011 | by Sajal Kayan | TweetRecently, I was evaluating CDN options for a client with some unique challenges. We ended up using Amazon CloudFront, but ill detail the options we looked at and what let us to this decision.
Some things to note:-
- We would serve CSS, JS, Images referred to from stylesheets and some website images thru the CDN.
- Due to the nature(trust me) of the site we expect a higher than normal miss rate. The access is spread across a wide number of urls, some may get lower hits.
- Speed is important. Website should be fast(er) from everywhere. The most important regions in order of priority are US, EU, AU and ROTW with US being most important.
- Anything on the site can change anytime, there is no build process as such. Any object anywhere can change, and change must be visible ASAP.
- Developers/designers shouldn’t be harassed to purge a file if they change something.
- CDN data usage : ~100 GB per month
The providers we looked at :-
MaxCDN: Almost sealed the deal.
Pros:-
- Cheap : $40 for first TB (must use in a year) + $99 per additional TB . On current usage rates this comes to say 0.04+ /GB.
- * Anycast/BGP routing : No way bad DNS server can mess up routing.
- Nice control panel, has a purge all option for just in case. Purges take effect almost instantly.
- Handles gzip well.
- Can have separate cache timings for caching in Browser and caching at CDN. – i.e. We can say not cache a file in browser level, but cache at CDN and purge when theres a change made.
Cons:-
- Poor global coverage. – No POP/Edge in Asia/AU – Deal Breaker
- Pages loaded same speed when testing from AU with or without CDN.
EdgeCast: Looked good at first, but poor gziping.
Pros:-
- Impressive list of networks
- Highly configurable control panel.
- Can have separate cache timings for caching in Browser and caching at CDN. – i.e. We can say not cache a file in browser level, but cache at CDN and purge when theres a change made.
Cons:-
- Gzippable files will not be gzipped for cache misses. – Deal Breaker
- Request from Edge server to origin is uncompressed.
- Expensive and wants higher commitments.
- DNS Based routing
CDNetworks: Didn’t look past price
Cons:-
- Ridiculously high price – Dealbreaker
Amazon CloudFront: WIN
Pros:-
- Testing showed our pages to be fastest from all regions when using cloudfront. YMMV
- No commitments – $0.15 – $0.2/GB (depends on where user accesses from) + negligible per request fee
- Client is already AWS user, one less account to maintain.
- No need to send gazillion emails to gazillions of people to get started. No bargaining.
Cons:-
- No POP/Edge in AU (but has in Singapore, Hong Kong and Tokyo)
- DNS based routing.
- Charges fee per request and per invalidation(purge) request.
- No control panel, invalidation requests need to be done by API only.
- Does not do gzipping, but honours Vary header and serves correct version based on what user asks.
- Can’t use querystring parameters for CDN cachebusting. CloudFront ignores querystrings.
Sidenote : Requests from CloudFront to origin are HTTP 1.0 . Nginx by default does not serve gzip to 1.0 request. gzip_http_version setting must be changed in order to use nginx as origin for CloudFront.
The system we architected adds something based on the file mtime as a part of the URL, so now we don’t need to any purges at the CDN. Also now we can have far future expires on all CDN’d objects cause if something changes, the URL would automagically change.
For us, the price and features are important, but whats more important is the results. We went with the provider with lesser features just because our pages loaded fastest with them.
