Sorry, someone asked me for more details off list; I was sitting down to
relax at the time and didn't feel like elaborating at that moment. ;)

So:

One of the major advantages of a CDN is the fact that they have a
distributed infrastructure over multiple geographies; when someone does a
DNS lookup it generally makes a best-effort attempt to direct them at the
infrastructure closest to them - and removes the need to connect to your
infrastructure at all (for that request). So it acts as a cache, offloading
work from your infrastructure, and it optimizes the end-user experience by
(hopefully) presenting them w/ a local place to make requests from, reducing
network delays.

In terms of total end-user time, it's often negligible for the 2nd path, but
it does mean another open network connection. And if the end-user is on a
network with poor connectivity to your infrastructure, it means that they
have to first traverse that bad network to yours, get the response back, and
then go ahead and make a 2nd request to the CDN after that. If it takes 100
ms for them to go to your server and get a response, that's 100 ms of delay
for each request. And if the request is for something like css or
javascript or static html that could potentially refer to other external
resources (therefore starting new requests), it can chain or stack or
whatever term you prefer.

Example:

static html page refers to css refers to image

If all of them are on the CDN and directly referred to, then your load time
is:
(dns lookup to cdn + round-trip for html + round-trip for css + round-trip
for image).

If they aren't and are just redirected, then your load time is:
(dns lookup to nginx + round-trip to nginx + dns lookup to cdn + round-trip
for html + round-trip to nginx + round-trip for css + round-trip to nginx +
round-trip for image)

(That's simplified, and can in many cases be worse than that. Don't forget
that if the content isn't cached, the CDN itself still has to make requests
back to your infrastructure the first time to get the objects into their
cache... so add 3 more round-trips to nginx, and these are for content, not
just redirects. :) )


Factor in the fact that now nginx is also now maintaining open connections,
your network is sustaining extra traffic (which you're probably paying for),
and the fact that the end-user is now subject to additional delays and work
on their client side to get to your page, and it's generally an easy choice.

If you just want to temporarily enable a CDN for something selectively and
are testing or aren't as concerned w/ those factors, sure, it's not a big
deal. But, as I mentioned, it does remove a lot of the benefit of the CDN
in the first place.

Again, there's a lot more to it than that, but for a 30 second primer I
think that'll do. (Good references: play w/ firebug and watch what your
site does, look into things like yslow or google pagespeed, check out
webpagetest.org's reports, etc.)

Nicholas


*Nicholas Tang**:*
VP, Dev Ops

nicholas.tang@livestream.com
|
t: +1 (646) 495 9707
|
m: +1 (347) 410 6066
|
111 8th Avenue, Floor 15, New York, NY 10011
[image: www.livestream.com] http://www.livestream.com/



On Fri, Jan 7, 2011 at 9:11 PM, Nicholas Tang
<nicholas.tang@livestream.com>wrote:

> The 2nd option defeats most of the purpose of a CDN.
>
> Nicholas
>
> *Nicholas Tang**:*
> VP, Dev Ops
>
> nicholas.tang@livestream.com
> |
> t: +1 (646) 495 9707
> |
> m: +1 (347) 410 6066
> |
> 111 8th Avenue, Floor 15, New York, NY 10011
> [image: www.livestream.com] http://www.livestream.com/
>
>
>
> On Fri, Jan 7, 2011 at 8:36 PM, Ilan Berkner <iberkner@gmail.com> wrote:
>
>> At this time we're delivering static content, in particular, audio files
>> ~5K in size directly through our server, for a number of reasons, we're
>> looking at moving delivery of these files to a remote storage / CDN
>> facility.
>>
>> Question re. URL requests for these files. Currently, these file are
>> served through a request like this:
>> http://www.ourdomain.com/sounds/a/alpha.mp3. If we switched to a remote
>> storage / CDN solution, the URL of course would change to something else.
>> There are 2 options ( I think ):
>>
>> 1. Modify the application code to make the the call directly to the new
>> URL.
>>
>> 2. Instruct Nginx through a location clause to redirect such traffic to
>> another URL, for example:
>>
>> location /sounds/*.mp3 {
>> rewrite http://www.cdn.com/$1 ...
>> }
>>
>> Is there a preferred way or does it matter? I guess the first option
>> would probably be preferred as it further reduces the work load done by the
>> server, even as simple as parsing the URL... Any thoughts / suggestions
>> would be appreciated.
>>
>> Also, does anyone have a recommendation / experience with any particular
>> remote storage / CDN such as Rackspace CloudFile, Amazon S3, Limelight,
>> CacheFly, etc?
>>
>> Thanks
>>
>> _______________________________________________
>> nginx mailing list
>> nginx@nginx.org
>> http://nginx.org/mailman/listinfo/nginx
>>
>>
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx