CDN questions

Server NGINX
1

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

2

The 2nd option defeats most of the purpose of a CDN.

Nicholas

Nicholas Tang*:*
VP, Dev Ops

[email protected]
|
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/

3

That’s a valid point, thanks!

On Fri, Jan 7, 2011 at 9:11 PM, Nicholas Tang

4

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

5

On Sat, Jan 8, 2011 at 8:52 AM, Ilan B. [email protected] 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:
http://wiki.nginx.org/HttpSubModule

or the third-party subs_filter which can handle regex:
http://wiki.nginx.org/HttpSubsModule

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’’
‘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

6

Thanks, why wouldn’t you do a location rewrite? What’s the advantage of
using the sub / subs module?

7

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. :wink:

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. :slight_smile: )

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

[email protected]
|
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

8

On Saturday, January 8, 2011, Ilan B. [email protected] 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