# CDN questions **URL:** \ **Category:** NGINX\ **Created:** [January 8, 2011, 2:37am UTC](https://www.ruby-forum.com/t/cdn-questions/201474 "2011-01-08T02:37:50Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![dubstep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@dubstep](https://www.ruby-forum.com/u/dubstep)\ **Post date:** [January 8, 2011, 2:37am UTC](https://www.ruby-forum.com/t/cdn-questions/201474/1 "2011-01-08T02:37:50Z")
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](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](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 ---
**Author:** ![iberci](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/a3d4f5/32.png) [@iberci](https://www.ruby-forum.com/u/iberci)\ **Post date:** [January 8, 2011, 3:12am UTC](https://www.ruby-forum.com/t/cdn-questions/201474/2 "2011-01-08T03:12:17Z")
The 2nd option defeats most of the purpose of a CDN. Nicholas _Nicholas Tang_\*:\* VP, Dev Ops removed\_email\_address@domain.invalid | 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)] [http://www.livestream.com/](http://www.livestream.com/) ---
**Author:** ![iberci](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/a3d4f5/32.png) [@iberci](https://www.ruby-forum.com/u/iberci)\ **Post date:** [January 8, 2011, 3:18am UTC](https://www.ruby-forum.com/t/cdn-questions/201474/3 "2011-01-08T03:18:35Z")
That’s a valid point, thanks! On Fri, Jan 7, 2011 at 9:11 PM, Nicholas Tang ---
**Author:** ![iberci](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/a3d4f5/32.png) [@iberci](https://www.ruby-forum.com/u/iberci)\ **Post date:** [January 8, 2011, 3:54pm UTC](https://www.ruby-forum.com/t/cdn-questions/201474/4 "2011-01-08T15:54:04Z")
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 ---
**Author:** ![iberci](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/a3d4f5/32.png) [@iberci](https://www.ruby-forum.com/u/iberci)\ **Post date:** [January 8, 2011, 8:37pm UTC](https://www.ruby-forum.com/t/cdn-questions/201474/5 "2011-01-08T20:37:39Z")
On Sat, Jan 8, 2011 at 8:52 AM, Ilan B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > 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 Don’t forget the sub\_filter module: > **[GitHub - nginxinc/nginx-wiki: ARCHIVED -- Source for the now archived NGINX Wiki...](https://github.com/nginxinc/nginx-wiki)** > > ARCHIVED -- Source for the now archived NGINX Wiki section of https://www.nginx.com or the third-party subs\_filter which can handle regex: > **[GitHub - nginxinc/nginx-wiki: ARCHIVED -- Source for the now archived NGINX Wiki...](https://github.com/nginxinc/nginx-wiki)** > > ARCHIVED -- Source for the now archived NGINX Wiki section of https://www.nginx.com We’ve used the former to test a CDN without modifying any application code or application configuration and without doing HTTP redirects. In your case something like this might help (assuming you keep the same path structure on the CDN as your site, or you are using origin fetch mode): sub\_filter ‘[www.ourdomain.com/sounds](http://www.ourdomain.com/sounds)’’ ‘[mybucket.cdndomain.com/sounds/](http://mybucket.cdndomain.com/sounds/)’; sub\_filter\_once off; If you need to do regex or multiple rules in a location, you’ll need the thrid-party subs\_filter instead of the built-in sub\_filter. – RPM ---
**Author:** ![iberci](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/a3d4f5/32.png) [@iberci](https://www.ruby-forum.com/u/iberci)\ **Post date:** [January 9, 2011, 5:14am UTC](https://www.ruby-forum.com/t/cdn-questions/201474/6 "2011-01-09T05:14:14Z")
Thanks, why wouldn’t you do a location rewrite? What’s the advantage of using the sub / subs module? ---
**Author:** ![iberci](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/a3d4f5/32.png) [@iberci](https://www.ruby-forum.com/u/iberci)\ **Post date:** [January 8, 2011, 3:13pm UTC](https://www.ruby-forum.com/t/cdn-questions/201474/7 "2011-01-08T15:13:18Z")
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](http://webpagetest.org)’s reports, etc.) Nicholas _Nicholas Tang_\*:\* VP, Dev Ops removed\_email\_address@domain.invalid | 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)] [http://www.livestream.com/](http://www.livestream.com/) On Fri, Jan 7, 2011 at 9:11 PM, Nicholas Tang ---
**Author:** ![iberci](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/a3d4f5/32.png) [@iberci](https://www.ruby-forum.com/u/iberci)\ **Post date:** [January 9, 2011, 6:37am UTC](https://www.ruby-forum.com/t/cdn-questions/201474/8 "2011-01-09T06:37:35Z")
On Saturday, January 8, 2011, Ilan B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Thanks, why wouldn’t you do a location rewrite? > What’s the advantage of using the sub / subs module? With sub module, you can change the URL of the audio file to point to the CDN inside the HTML as it is delivered. This avoids the extra round-trip of a redirect as discussed previously. The net effect is the same as changing the urls in your site, but it is a simple nginx config so it is easy to tweak. You can also use variables, so A/B testing or a pilot rollout to say 10% of visitors could be done as well using if or map directives to set the substitution variable. – RPM – RPM