CDN questions...

[Ilan Berkner]

That's a valid point, thanks!

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/20110107/43a95175/attachment-0001.html>