CDN questions...

[Nicholas Tang]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20110107/d105a2ba/attachment.html>