CDN questions...

[Ilan Berkner]

Thanks for the details, once I realized the difference, going directly to
the CDN is the whole point.

Rackspace has an interesting product which combines storage + CDN so for us
that kind solution may work well, but we're still exploring.

Thanks

On Sat, Jan 8, 2011 at 9:11 AM, Nicholas Tang
<nicholas.tang at livestream.com>wrote:

> 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 at 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 at livestream.com> wrote:
>
>> The 2nd option defeats most of the purpose of a CDN.
>>
>> Nicholas
>>
>> *Nicholas Tang**:*
>> VP, Dev Ops
>>
>> nicholas.tang at 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 at 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 at nginx.org
>>> http://nginx.org/mailman/listinfo/nginx
>>>
>>>
>>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://nginx.org/mailman/listinfo/nginx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20110108/933db716/attachment-0001.html>