Make your website faster using Content Delivery Network

Every request from a browser goes to your server traveling
through the Internet backbones that spans the world. The number of
countries, continents, oceans a request has to go through to reach
your server, the slower it is. For example, if you have your
servers in USA and someone from Australia is browsing your site,
each request is literary crossing the planet from one end to the
other in order to reach your server and then come back again to the
browser. If your site has large number of static files like images,
css, javascript; sending request for each of them and downloading
them across the world takes significant amount of time. If you
could setup a server in Australia and redirect users to your
Australian server, then each request would take fraction of the
time it takes to reach USA. Not only the network latency will be
lower but also the data transfer rate will be faster and thus
static content will download a lot faster. This will give
significant performance improvement on the user’s end if your
website is rich in static content. Moreover, ISPs provide far
greater speed for country wide network compared to the internet
because each country generally has handful of connectivity to the
Internet backbone that are shared by all ISPs within the country.
As a result, users having 4mbps broadband connection will get the
full 4mbps speed from servers that are within the same country. But
they will get as low as 512kbps from servers which are outside the
country. Thus having a server in the same country significantly
improves site download speed and responsiveness.

clip_image002[4]

Above figure shows average response time for www.pageflakes.com from
Washington, DC, where the servers are in Dallas, Texas. The average
response time is around 0.4 seconds. This response includes server
side execution time as well. Generally it takes around 0.3 to 0.35
seconds to execute the page on the server. So, time spent on
network is around 0.05 seconds or 50ms. This is a really fast
connectivity as there are only 4 to 6 hops to reach Dallas from
Washington DC.

clip_image004[4]

This figure shows average response time from Sydney,
Australia. The average response time is 1.5 seconds which is
significantly higher than Washington DC. It’s almost 4 times
compared to USA. There’s almost 1.2 seconds overhead on network
only. Moreover, there are around 17 to 23 hops from Sydney to
Dallas. So, the site downloads at least 4 times slower in Australia
than it is from anywhere in USA.

A content delivery network (CDN) is a system of computers
networked together across the Internet. The computers cooperate
transparently to deliver content (especially large media content)
to end users. CDN nodes (cluster of servers in a specific location)
are deployed in multiple locations, often over multiple backbones.
These nodes cooperate with each other to serve requests for content
by end users. They also transparently move content behind the
scenes to optimize the delivery process. CDN serves request by
intelligently choosing the nearest server. It looks for the fastest
connectivity between your computer to a nearest node that has the
content you are looking for. The number of nodes in different
countries and the number of redundant backbone connectivity a CDN
has measures its strength. Some of the most popular CDNs are
Akamai, Limelight, EdgeCast. Akamai is used by large companies like
Microsoft, Yahoo, AOL. It’s comparatively expensive solution.
However, Akamai has the best performance throughout the world
because they have servers in almost every prominent city in the
world. However, Akamai is very expensive and they only accept a
customer who can spend minimum 5K on CDN per month. For smaller
companies, Edgecast is a more affordable solution.

clip_image006[4]

This figure shows CDN Nodes that is closest to the browser
intercepts traffic and serves response. If it does not have the
response in cache, it fetches it from origin server using a faster
route and much more optimized connectivity that the browser’s
ISP can provide. If the content is already cached, then it’s
served directly from the node

There are generally two types of CDN. One is where you upload
content to CDN’s servers via FTP and you get a subdomain in their
domain like dropthings.somecdn.net. You change all the URL of
static content throughout your site to download content from the
CDN domain instead of relative URL to your own domain. So, a URL
like /logo.gif will be renamed to
http://dropthings.somecdn.net/logo.gif. This is easy to configure
but has maintenance problems. You will have to keep CDN’s
store synchronized with the files all the time. Deployment becomes
complicated because you need to update both your website and the
CDN store at the same time. Example of such a CDN (which is very
cheap) is Cachefly.

A more convenient approach is to store static content on your
own site but use domain aliasing. You can store your content in a
subdomain that points to your own domain like
static.dropthings.com. Then you use CNAME to map that subdomain to
a CDN’s nameserver like cache.somecdn. net. When a
browser tries to resolve static.dropthigns.com, the DNS lookup
request goes to the CDN nameserver. The nameserver then returns IP
of a CDN node which is closest to you and can give you the best
download performance. Browser then sends requests for files to that
CDN node. When CDN node sees the request, it checks whether it has
the content already cached. If it is cached, it delivers the
content directly from its local store. If not, it makes a request
to your server and then looks at the cache header generated in
response. Based on the cache header it decides how long to cache
the response in its own cache. In the meantime, browser does not
wait for CDN node to get content and return to it. CDN does
interesting trick on the internet backbone to actually route
request to the origin server so that the browser gets the response
directly served from origin server while CDN is updating its
cache. Sometimes CDN act as a proxy, intercepting each
request and then fetching uncached content from origin using a
faster route and optimized connectivity to the origin server.

Share on Tumblr

13 thoughts on “Make your website faster using Content Delivery Network”

  1. I guess you wanted to make things simpler, but it’s not true that every request to your files is always handled by your server/s. There are many caching mechanisms which span local machines as well as intermediate servers. Then many organizations use proxy servers, hosting companies might present clustered or multiclustered acrhitectures, and so on.

    Thus, many of your static files might not be retrieved from your original locations more than once. Caching is a vast topic, and CDNs seem to be the best solution just for websites which really need them, while cheaper and more maintainable alternatives are usually far better for most of the others.

  2. Thanks for the info. Was very good.

    One advise, please do post a little faster. I really like your writing :-).

  3. Interesting.

    The diagrams are superb.

    Now, I am off to check some of the names you mentioned in your article. One that I had forgotten about is cachefly 🙂

  5. the easiest implementation could be, setting up reverse proxy on the local node. reverse proxy has more control over the content it caches(you can easily invalidate any cache, you can set cachable url pattern). so this could be applied for dynamic content as well with expire time from request header.

    though this is bit different in streaming technology, but much easier solution exists. you can multicast your stream from local node. where local node maintains a single connection (or more for load balancing) to picking stream.

    the advantage about CDN is the latency it reduces.

    btw, don’t u have any node herein BD?

  6. Very nice article.

    Reverse proxy solutions doesn’t work for all web sites, but it sure speeds up file caching and delivery.

  9. Hi,you always fly higer & higher :)I regularly read your post and learn a lot.Thanks a lot Omar.

    Keep it up. 🙂

  10. This is one of the best article on net i have ever came across.

    Your article is very useful to me in improving my website performance. I have also read your article on code project. Thanks for sharing such a useful information.

    I would look forward for this type of articles in future from you.

    Thanks,
    Jordon

  12. Pingback: http://%/bvyhsei

Leave a Reply