CGN vs. CDN

March 16, 2009 on 1:24 pm | In New Features, Tech News by Josh Jones | 49 Comments

Just your average US Navy nuclear-powered guided missile cruiser.

After my freshman year in college I went back home for the summer and had a strange job at a little two-man pre-press graphics shop in Vienna, Virginia called “Color Graphics Network” (not the inspiration for New Dream Network – parent company of DreamHost).

The guy who owned it was named Ricky Dee (awesome name), and I vaguely knew his son Howie Dee (awesome name) from high school. It was a pretty cushy job compared to my previous one.

What CGN did was take large (dozens of MB!) graphic files from publishers, and turn them into high-resolution negatives suitable for printing presses. This was in 1995, and the files would come on SyQuest drives via courier. By the end of the summer, some people were starting to send zip disks!

88MB and WE WERE LUCKY!

After a few weeks, I was sort of thinking everybody could probably distribute this content a little better, maybe via a series of tubes or something. But really, with the slowness of dial-up, the size of these files, and the publication deadlines they needed to meet, this was the only way to go at the time.

Not that I’ve kept in touch, but I imagine that these days there’s a lot less padded envelope use over at CGN. I’m sure Mr. Sneakernet has finally been usurped by Mr. Internet!

Mr. Internet, meet Mrs. Fist.

Yep, Mr. Internet has gotten a bit faster in the last 14 years. Way fast. More than fast enough for whatever kind of multi-GB files Ricky Dee (or maybe it’s Howie now!) must be dealing with today.

And yet, still not fast enough for everybody.

People need to pose more.

Hence the rise of the CDN (“Content Delivery Network”). Although you can pretty much get between any two points on the Internet in under .3 seconds, sometimes that’s a little too slow. After 14 years of the web, people are really sick of waiting. Even a second. Even a third of a second.

In fact, there are a bunch of studies that show things like “There’s a 10% drop in conversions for each 1 second increase in load time.” and “Google lost 20% of their ad clicks when their page results took .9 seconds to load as opposed to .4.”

Fortunately, a decade ago Akamai discovered (I think it was them!) that putting multiple copies of the same content all over the Internet could cut that .3 second access time down to .03 seconds… and that some people would pay for it!

That's me on the bottom left.

Today there are dozens of companies offering CDNs, not the least of whom is Amazon, who four months ago launched “CloudFront” as part of their Amazon Web Services.

The cool thing about CloudFront (besides, like DreamHost, it being in CamelCaps), is like all of the Amazon Web Services, it’s completely pay-as-you-go, and completely accessible via an API.

The downside of CloudFront is, just like with all APIs… you have to be a programmer to be able to use it!

And what's wrong with that?

Until now!!?!

We just added a new Amazon CloudFront area to our panel (under “Goodies”)!

Now all you have to do to take advantage of a world-wide pay-as-you-go content delivery network run by Amazon is click a few buttons!

Or, more specifically:

  1. Sign up with AWS.
  2. Go to our panel and let us know what domain (maybe something like “static.domain.com”) you’d like to use and what path we should upload the content to Amazon from!

And for this amazing convenience, what do we want from you?

I would say nothing, but the truth is just $3.95/month on top of whatever Amazon bills you! No matter how many CDNs you set up!

Or buy one of these a month and get FAT!

How does it work?

I was always a little confused, technically, about how CDNs worked. After all, there must be at least one centralized service that figures out where to send people, right?!

Well, while testing out CloudFront, I figured it out… that one centralized service is DNS!

The DNS servers for a CDN are dynamic and tricky… and it’s they who figure out which “edge” of the CDN is closest to you, based on your IP.

So for example, if I (in Los Angeles) do a ping on images.groo.com, my results are:

ping images.groo.com

PING d2onuwnge3cit8.lax1.cloudfront.net (216.137.45.27) 56(84) bytes of data.
64 bytes from server-216-137-45-27.lax1.cloudfront.net (216.137.45.27): icmp_seq=1 ttl=56 time=1.29 ms
64 bytes from server-216-137-45-27.lax1.cloudfront.net (216.137.45.27): icmp_seq=2 ttl=56 time=1.21 ms
64 bytes from server-216-137-45-27.lax1.cloudfront.net (216.137.45.27): icmp_seq=3 ttl=56 time=1.31 ms
64 bytes from server-216-137-45-27.lax1.cloudfront.net (216.137.45.27): icmp_seq=4 ttl=56 time=1.18 ms
64 bytes from server-216-137-45-27.lax1.cloudfront.net (216.137.45.27): icmp_seq=5 ttl=56 time=1.32 ms

Now you give it a shot and check out what cloudfront.net server you get for “images.groo.com” .. and how the ping time it is! Maybe even post your results in the comments?

I’m not sure how old Ricky Dee is going to compete.


49 Responses to “CGN vs. CDN”

  1. Dan Says:
    March 16th, 2009 at 1:56 pm

    Pinged in West Lafayette, IN

    Pinging d2onuwnge3cit8.cloudfront.net [216.137.39.170

    Reply from 216.137.39.170: bytes=32 time=15ms TTL=55
    Reply from 216.137.39.170: bytes=32 time=15ms TTL=55
    Reply from 216.137.39.170: bytes=32 time=15ms TTL=55
    Reply from 216.137.39.170: bytes=32 time=16ms TTL=55

  2. Pete Says:
    March 16th, 2009 at 4:41 pm

    Results from Dundee, Scotland
    ping images.groo.com

    Pinging d2onuwnge3cit8.cloudfront.net [216.137.63.49] with 32 bytes of data:
    Reply from 216.137.63.49: bytes=32 time=25ms TTL=52
    Reply from 216.137.63.49: bytes=32 time=26ms TTL=52
    Reply from 216.137.63.49: bytes=32 time=24ms TTL=52
    Reply from 216.137.63.49: bytes=32 time=26ms TTL=52

  3. Glen Says:
    March 16th, 2009 at 4:47 pm

    Results from Brea, CA

    PING d2onuwnge3cit8.cloudfront.net (216.137.45.71): 56 data bytes
    64 bytes from 216.137.45.71: icmp_seq=0 ttl=57 time=7.923 ms
    64 bytes from 216.137.45.71: icmp_seq=1 ttl=57 time=7.691 ms
    64 bytes from 216.137.45.71: icmp_seq=2 ttl=57 time=7.147 ms
    64 bytes from 216.137.45.71: icmp_seq=3 ttl=57 time=7.632 ms
    64 bytes from 216.137.45.71: icmp_seq=4 ttl=57 time=7.101 ms
    64 bytes from 216.137.45.71: icmp_seq=5 ttl=57 time=7.584 ms
    64 bytes from 216.137.45.71: icmp_seq=6 ttl=57 time=7.877 ms
    64 bytes from 216.137.45.71: icmp_seq=7 ttl=57 time=7.177 ms

  4. MG Says:
    March 16th, 2009 at 5:59 pm

    From San Francisco:

    PING d2onuwnge3cit8.cloudfront.net (216.137.37.16): 56 data bytes
    64 bytes from 216.137.37.16: icmp_seq=0 ttl=58 time=20.673 ms
    64 bytes from 216.137.37.16: icmp_seq=1 ttl=58 time=23.919 ms
    64 bytes from 216.137.37.16: icmp_seq=2 ttl=58 time=23.057 ms
    64 bytes from 216.137.37.16: icmp_seq=3 ttl=58 time=23.506 ms
    64 bytes from 216.137.37.16: icmp_seq=4 ttl=58 time=22.090 ms
    ^C
    — d2onuwnge3cit8.cloudfront.net ping statistics —
    6 packets transmitted, 5 packets received, 16% packet loss
    round-trip min/avg/max/stddev = 20.673/22.649/23.919/1.160 ms

  5. Corey Says:
    March 16th, 2009 at 6:48 pm

    From Seattle, WA

    PING d2onuwnge3cit8.sea4.cloudfront.net (216.137.35.122): 56 data bytes
    64 bytes from 216.137.35.122: icmp_seq=0 ttl=56 time=5798.117 ms
    64 bytes from 216.137.35.122: icmp_seq=1 ttl=56 time=8.268 ms
    64 bytes from 216.137.35.122: icmp_seq=2 ttl=56 time=7.934 ms
    64 bytes from 216.137.35.122: icmp_seq=3 ttl=56 time=7.540 ms
    64 bytes from 216.137.35.122: icmp_seq=4 ttl=56 time=8.052 ms

  6. Dylan Says:
    March 16th, 2009 at 6:50 pm

    Pinging d2onuwnge3cit8.sfo4.cloudfront.net [216.137.37.126] with 32 bytes of data:

    Reply from 216.137.37.126: bytes=32 time=166ms TTL=56
    Reply from 216.137.37.126: bytes=32 time=165ms TTL=56
    Reply from 216.137.37.126: bytes=32 time=165ms TTL=56
    Reply from 216.137.37.126: bytes=32 time=165ms TTL=56

    Ping statistics for 216.137.37.126:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
    Minimum = 165ms, Maximum = 166ms, Average = 165ms

  7. Chris Says:
    March 16th, 2009 at 7:18 pm

    From Waterloo, Ontario

    PING d2onuwnge3cit8.cloudfront.net (216.137.33.145): 56 data bytes
    64 bytes from 216.137.33.145: icmp_seq=0 ttl=46 time=53.138 ms
    64 bytes from 216.137.33.145: icmp_seq=1 ttl=46 time=51.330 ms
    64 bytes from 216.137.33.145: icmp_seq=2 ttl=46 time=46.670 ms
    64 bytes from 216.137.33.145: icmp_seq=3 ttl=46 time=48.548 ms

  8. Tim Says:
    March 16th, 2009 at 7:19 pm

    Reply from 216.137.43.99: bytes=32 time=143ms TTL=51
    Reply from 216.137.43.99: bytes=32 time=169ms TTL=51
    Reply from 216.137.43.99: bytes=32 time=73ms TTL=51
    Reply from 216.137.43.99: bytes=32 time=66ms TTL=51

    Ping statistics for 216.137.43.99:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
    Minimum = 66ms, Maximum = 169ms, Average = 112ms

  9. Daniel Says:
    March 16th, 2009 at 7:19 pm

    Pinging d2onuwnge3cit8.cloudfront.net [216.137.39.10
    Reply from 216.137.39.104: bytes=32 time=55ms TTL=52
    Reply from 216.137.39.104: bytes=32 time=54ms TTL=52
    Reply from 216.137.39.104: bytes=32 time=53ms TTL=52
    Reply from 216.137.39.104: bytes=32 time=52ms TTL=52

  10. Tim Says:
    March 16th, 2009 at 7:21 pm

    Does CloudFront support GZIP compression yet?

  11. Daniel Costalis Says:
    March 16th, 2009 at 7:23 pm

    ping images.groo.com

    Ping request could not find host images.groo.com. Please check the name and try
    again.

    http://isitdownorisit.me/images.groo.com

    images.groo.com isn’t working on my end either!

    Returned code 403

    Hmm…

  12. Tim Says:
    March 16th, 2009 at 7:24 pm

    Also, does CloudFront support either ETAGs or Last-Modified header.

    No need to be sending to the browser content that could be cached.

  13. temple Says:
    March 16th, 2009 at 8:13 pm

    Pinging d2onuwnge3cit8.hkg1.cloudfront.net [216.137.55.206] with 32 bytes of dat
    a:

    Reply from 216.137.55.206: bytes=32 time=186ms TTL=48
    Reply from 216.137.55.206: bytes=32 time=198ms TTL=48
    Reply from 216.137.55.206: bytes=32 time=165ms TTL=49
    Reply from 216.137.55.206: bytes=32 time=187ms TTL=48

    Ping statistics for 216.137.55.206:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
    Minimum = 165ms, Maximum = 198ms, Average = 184ms

  14. Greg Says:
    March 16th, 2009 at 8:15 pm

    Unless you are getting average response time < 100ms – there’s not much to take notice off.

    Great new feature though!

  15. John Says:
    March 16th, 2009 at 8:42 pm

    Philippines:

    PING d2onuwnge3cit8.cloudfront.net (216.137.37.182): 56 data bytes
    64 bytes from 216.137.37.182: icmp_seq=0 ttl=56 time=611.115 ms
    64 bytes from 216.137.37.182: icmp_seq=1 ttl=56 time=532.380 ms
    64 bytes from 216.137.37.182: icmp_seq=2 ttl=56 time=455.587 ms
    64 bytes from 216.137.37.182: icmp_seq=3 ttl=56 time=479.840 ms
    64 bytes from 216.137.37.182: icmp_seq=4 ttl=56 time=604.638 ms

  16. Ted Says:
    March 16th, 2009 at 10:28 pm

    What’s exciting about ping times? DNS info is more exciting. Use host, dig, or nslookup.

    $ host images.groo.com
    images.groo.com is an alias for d2onuwnge3cit8.cloudfront.net.
    d2onuwnge3cit8.cloudfront.net has address 216.137.41.66
    d2onuwnge3cit8.cloudfront.net has address 216.137.41.119
    d2onuwnge3cit8.cloudfront.net has address 216.137.41.67
    d2onuwnge3cit8.cloudfront.net has address 216.137.41.139
    d2onuwnge3cit8.cloudfront.net has address 216.137.41.221
    d2onuwnge3cit8.cloudfront.net has address 216.137.41.199
    d2onuwnge3cit8.cloudfront.net has address 216.137.41.151
    d2onuwnge3cit8.cloudfront.net has address 216.137.41.157

  17. Ted Says:
    March 16th, 2009 at 10:30 pm

    From my DH server (popcorn):

    $ host images.groo.com
    images.groo.com CNAME d2onuwnge3cit8.cloudfront.net
    d2onuwnge3cit8.cloudfront.net CNAME d2onuwnge3cit8.lax1.cloudfront.net
    d2onuwnge3cit8.lax1.cloudfront.net A 216.137.45.240
    d2onuwnge3cit8.lax1.cloudfront.net A 216.137.45.82
    d2onuwnge3cit8.lax1.cloudfront.net A 216.137.45.107
    d2onuwnge3cit8.lax1.cloudfront.net A 216.137.45.32
    d2onuwnge3cit8.lax1.cloudfront.net A 216.137.45.94
    d2onuwnge3cit8.lax1.cloudfront.net A 216.137.45.6
    d2onuwnge3cit8.lax1.cloudfront.net A 216.137.45.42
    d2onuwnge3cit8.lax1.cloudfront.net A 216.137.45.123

  18. Yosi Taguri Says:
    March 17th, 2009 at 1:38 am

    from Israel:

    Pinging d2onuwnge3cit8.fra2.cloudfront.net [216.137.61.204] with 32 bytes of data:
    Reply from 216.137.61.204: bytes=32 time=91ms TTL=55
    Reply from 216.137.61.204: bytes=32 time=76ms TTL=55
    Reply from 216.137.61.204: bytes=32 time=149ms TTL=55
    Reply from 216.137.61.204: bytes=32 time=146ms TTL=55

  19. David Says:
    March 17th, 2009 at 1:50 am

    From Spain

    Haciendo ping a d2onuwnge3cit8.fra2.cloudfront.net [216.137.61.212] con 32 bytes
    de datos:

    Respuesta desde 216.137.61.212: bytes=32 tiempo=91ms TTL=55
    Respuesta desde 216.137.61.212: bytes=32 tiempo=92ms TTL=55
    Respuesta desde 216.137.61.212: bytes=32 tiempo=91ms TTL=55
    Respuesta desde 216.137.61.212: bytes=32 tiempo=86ms TTL=55

  20. Michel Says:
    March 17th, 2009 at 3:28 am

    Pinging d2onuwnge3cit8.fra2.cloudfront.net [216.137.61.97] with 32 bytes of data
    :

    Reply from 216.137.61.97: bytes=32 time=38ms TTL=52
    Reply from 216.137.61.97: bytes=32 time=43ms TTL=52
    Reply from 216.137.61.97: bytes=32 time=49ms TTL=52
    Reply from 216.137.61.97: bytes=32 time=54ms TTL=52

    –

    Here be my results :-)

    (From Bulgaria)

  21. Guilherme Says:
    March 17th, 2009 at 6:30 am

    From Brazil

    PING d2onuwnge3cit8.cloudfront.net (216.137.41.51) 56(84) bytes of data.
    (216.137.41.51): icmp_seq=1 ttl=44 time=269 ms
    (216.137.41.51): icmp_seq=2 ttl=44 time=779 ms
    (216.137.41.51): icmp_seq=3 ttl=44 time=1028 ms
    (216.137.41.51): icmp_seq=5 ttl=44 time=208 ms
    (216.137.41.51): icmp_seq=6 ttl=44 time=258 ms
    (216.137.41.51): icmp_seq=7 ttl=44 time=210 ms
    (216.137.41.51): icmp_seq=8 ttl=44 time=227 ms
    (216.137.41.51): icmp_seq=9 ttl=44 time=281 ms

    rtt min/avg/max/mdev = 208.928/408.186/1028.456/294.074 ms

  22. Ryan Says:
    March 17th, 2009 at 6:51 am

    From Sandy Hook, CT:

    Pinging d2onuwnge3cit8.iad2.cloudfront.net [216.137.33.233] with 32 bytes of data:

    Reply from 216.137.33.233: bytes=32 time=55ms TTL=53
    Reply from 216.137.33.233: bytes=32 time=55ms TTL=53
    Reply from 216.137.33.233: bytes=32 time=113ms TTL=53
    Reply from 216.137.33.233: bytes=32 time=113ms TTL=53

    Ping statistics for 216.137.33.233:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
    Minimum = 55ms, Maximum = 113ms, Average = 84ms

  23. mark Says:
    March 17th, 2009 at 7:09 am

    From Minneapolis – qwest isp
    ping images.groo.com

    Pinging d2onuwnge3cit8.dfw3.cloudfront.net [216.137.43.70] with 32 bytes of data
    :
    Reply from 216.137.43.70: bytes=32 time=68ms TTL=54
    Reply from 216.137.43.70: bytes=32 time=68ms TTL=54
    Reply from 216.137.43.70: bytes=32 time=68ms TTL=54
    Reply from 216.137.43.70: bytes=32 time=68ms TTL=54

    Ping statistics for 216.137.43.70:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
    Minimum = 68ms, Maximum = 68ms, Average = 68ms

  24. Fred K Says:
    March 17th, 2009 at 7:09 am

    Holy Cow, Dreamhost offering Lighttpd as an alternative on Private Servers!!!

    I love you guys (just wish you would have picked NGINX, which doesn’t leak memory like the fire hose of Lighttpd)

  25. Aaron Says:
    March 17th, 2009 at 7:20 am

    Seems strange to me that Lighttpd would be picked since it currently undergoing an **ENTIRE REWRITE**.

    More information can be found at their blog.

    http://blog.lighttpd.net/

    Though, as previous commentors have stated – I’m crazy excited to have a low memory web server option for my Private Server. Seriously, MANY MANY THANKS!!!

  26. Agusti Pons Says:
    March 17th, 2009 at 8:05 am

    From Barcelona, Catalonia, Spain

    Haciendo ping a d2onuwnge3cit8.lhr3.cloudfront.net [216.137.63.39]
    de datos:

    Respuesta desde 216.137.63.39: bytes=32 tiempo=86ms TTL=55
    Respuesta desde 216.137.63.39: bytes=32 tiempo=87ms TTL=55
    Respuesta desde 216.137.63.39: bytes=32 tiempo=87ms TTL=55
    Respuesta desde 216.137.63.39: bytes=32 tiempo=90ms TTL=55

    Estadísticas de ping para 216.137.63.39:
    Paquetes: enviados = 4, recibidos = 4, perdidos = 0
    (0% perdidos),
    Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 86ms, Máximo = 90ms, Media = 87ms

  27. Real Estate in Baja Says:
    March 17th, 2009 at 8:10 am

    From Baja, Mexico.
    =============================
    Pinging d2onuwnge3cit8.cloudfront.net [216.137.45.126] with 32 bytes of data:

    Reply from 216.137.45.126: bytes=32 time=18ms TTL=55
    Reply from 216.137.45.126: bytes=32 time=19ms TTL=55
    Reply from 216.137.45.126: bytes=32 time=17ms TTL=55
    Reply from 216.137.45.126: bytes=32 time=17ms TTL=55

    Ping statistics for 216.137.45.126:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
    Minimum = 17ms, Maximum = 19ms, Average = 17ms
    =============================

    Sharon

  28. James Says:
    March 17th, 2009 at 9:28 am

    From Ecuador:
    ====================================
    # ping images.groo.com
    PING d2onuwnge3cit8.cloudfront.net (216.137.33.103): 56 data bytes
    64 bytes from 216.137.33.103: icmp_seq=0 ttl=53 time=115.186 ms
    64 bytes from 216.137.33.103: icmp_seq=1 ttl=53 time=90.354 ms
    64 bytes from 216.137.33.103: icmp_seq=2 ttl=53 time=93.552 ms
    64 bytes from 216.137.33.103: icmp_seq=3 ttl=53 time=91.891 ms
    64 bytes from 216.137.33.103: icmp_seq=4 ttl=53 time=114.440 ms
    64 bytes from 216.137.33.103: icmp_seq=5 ttl=53 time=92.022 ms
    64 bytes from 216.137.33.103: icmp_seq=6 ttl=53 time=103.230 ms
    64 bytes from 216.137.33.103: icmp_seq=7 ttl=53 time=111.770 ms
    64 bytes from 216.137.33.103: icmp_seq=8 ttl=53 time=100.774 ms
    64 bytes from 216.137.33.103: icmp_seq=9 ttl=53 time=102.562 ms
    64 bytes from 216.137.33.103: icmp_seq=10 ttl=53 time=91.836 ms
    64 bytes from 216.137.33.103: icmp_seq=11 ttl=53 time=114.216 ms
    64 bytes from 216.137.33.103: icmp_seq=12 ttl=53 time=92.029 ms
    ^C
    — d2onuwnge3cit8.cloudfront.net ping statistics —
    13 packets transmitted, 13 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 90.354/101.066/115.186/9.514 ms

    ==============================

    James

  29. eli Says:
    March 17th, 2009 at 10:08 am

    I’m in north Florida near Tallahassee, and I hit a Miami server. Cool!

  30. Jorge Says:
    March 17th, 2009 at 11:36 am

    I already use Amazon S3 to host static images. What can cloudfront do for me and do I need it to get the most out of S3?

  31. Jason Bunston Says:
    March 17th, 2009 at 3:12 pm

    Toronto ON – Bell ADSL

    PING d2onuwnge3cit8.ewr2.cloudfront.net (216.137.41.100): 56 data bytes
    64 bytes from 216.137.41.100: icmp_seq=0 ttl=53 time=29.179 ms
    64 bytes from 216.137.41.100: icmp_seq=1 ttl=53 time=29.448 ms
    64 bytes from 216.137.41.100: icmp_seq=2 ttl=53 time=29.774 ms
    64 bytes from 216.137.41.100: icmp_seq=3 ttl=53 time=32.802 ms
    64 bytes from 216.137.41.100: icmp_seq=4 ttl=53 time=33.362 ms
    64 bytes from 216.137.41.100: icmp_seq=5 ttl=53 time=33.155 ms
    64 bytes from 216.137.41.100: icmp_seq=6 ttl=53 time=29.298 ms
    64 bytes from 216.137.41.100: icmp_seq=7 ttl=53 time=33.331 ms
    64 bytes from 216.137.41.100: icmp_seq=8 ttl=53 time=29.363 ms
    64 bytes from 216.137.41.100: icmp_seq=9 ttl=53 time=32.943 ms
    64 bytes from 216.137.41.100: icmp_seq=10 ttl=53 time=33.289 ms

  32. Jason Bunston Says:
    March 17th, 2009 at 3:16 pm

    Aw crap.. well so much for geolocating us…I’m in toronto, and that server is here:

    IP: 216.137.41.100 Location:
    Seattle, WASHINGTON, United States (Terabeam Networks, Inc)

  33. Dimitri Says:
    March 17th, 2009 at 3:54 pm

    It is a lot of text in this post.
    Can you tell in plain English what CDN does for a DH user and what locations would benefit from it? It is 200ms to your DNS from Australia regardless. So what is the point of all this?

  34. Daniel Costalis Says:
    March 17th, 2009 at 6:12 pm

    Now it works. Looked like the service was down for a while. Wasn’t accepting my ping.

    Pinging d2onuwnge3cit8.stl2.cloudfront.net [216.137.39.126] with 32 bytes of data:
    Reply from 216.137.39.126: bytes=32 time=68ms TTL=53
    Reply from 216.137.39.126: bytes=32 time=26ms TTL=53
    Reply from 216.137.39.126: bytes=32 time=20ms TTL=53
    Reply from 216.137.39.126: bytes=32 time=19ms TTL=53

    Ping statistics for 216.137.39.126:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
    Minimum = 19ms, Maximum = 68ms, Average = 33ms

  35. Mangochutney Says:
    March 18th, 2009 at 1:28 am

    From Australia.

    Dude – are we that far from the EDGE ?

    ping images.groo.com
    PING d2onuwnge3cit8.sfo4.cloudfront.net (216.137.37.121): 56 data bytes
    64 bytes from 216.137.37.121: icmp_seq=0 ttl=55 time=221.192 ms
    64 bytes from 216.137.37.121: icmp_seq=1 ttl=55 time=204.170 ms
    64 bytes from 216.137.37.121: icmp_seq=2 ttl=55 time=189.133 ms
    64 bytes from 216.137.37.121: icmp_seq=3 ttl=55 time=258.618 ms
    64 bytes from 216.137.37.121: icmp_seq=4 ttl=55 time=203.453 ms
    64 bytes from 216.137.37.121: icmp_seq=5 ttl=55 time=175.814 ms
    64 bytes from 216.137.37.121: icmp_seq=6 ttl=55 time=174.361 ms
    64 bytes from 216.137.37.121: icmp_seq=7 ttl=55 time=273.424 ms
    64 bytes from 216.137.37.121: icmp_seq=8 ttl=55 time=174.407 ms
    64 bytes from 216.137.37.121: icmp_seq=9 ttl=55 time=205.749 ms
    64 bytes from 216.137.37.121: icmp_seq=10 ttl=55 time=256.101 ms
    64 bytes from 216.137.37.121: icmp_seq=11 ttl=55 time=199.280 ms
    64 bytes from 216.137.37.121: icmp_seq=12 ttl=55 time=177.253 ms
    64 bytes from 216.137.37.121: icmp_seq=13 ttl=55 time=239.189 ms
    64 bytes from 216.137.37.121: icmp_seq=14 ttl=55 time=222.497 ms
    64 bytes from 216.137.37.121: icmp_seq=15 ttl=55 time=204.038 ms
    ^C
    — d2onuwnge3cit8.sfo4.cloudfront.net ping statistics —
    17 packets transmitted, 16 packets received, 5% packet loss
    round-trip min/avg/max/stddev = 174.361/211.167/273.424/30.702 ms

  36. Electronic Lint Filter Says:
    March 18th, 2009 at 1:56 pm

    You should host the images on this blog on CloudFront and see how it goes

  37. Josh Jones Says:
    March 18th, 2009 at 4:23 pm

    “Can you tell in plain English what CDN does for a DH user and what locations would benefit from it? It is 200ms to your DNS from Australia regardless. So what is the point of all this?”

    Hey!

    Well, the idea is that, even though it’s still going to take just as long for the DNS request, that’s just one (small) request, and the results are cached. So then, when your web browser moves along to actually requesting the rest of the files from the server that that DNS request pointed you to, they’re quicker.

    Of course, if it’s 200ms from Australia to the nearest CloudFront server, that’s probably not much better than just straight to DreamHost. But on the other hand, some of your site visitors may be from Spain where it’s only 90ms to CloudFront, but I assume more to DreamHost!

    “I already use Amazon S3 to host static images. What can cloudfront do for me and do I need it to get the most out of S3?”

    CloudFront would take those static images in that S3 bucket in a single Amazon data center (or maybe two) and now spread it out across ALL of Amazon’s data centers around the world… plus it will actually serve it from the data center closest to the person requesting the file. Right now, there are multiple data centers serving your file, but that’s just for redundancy purposes, not performance. No matter where somebody is, they still connect to a random Amazon data center, not the one closest to them.

  38. Ben Strawson Says:
    March 19th, 2009 at 3:17 am

    Does CloudFront support GZIP compression yet?
    Also, does CloudFront support either ETAGs or Last-Modified header.

    You can set headers for files stored in S3 that will be sent to the browser when the content is served. These will also be sent when using CloudFront to server the content.

    So you just need to set headers for ETag and Last-Modified when you upload the content. If you want to serve compressed content, then you could GZip it and set the appropriate header. However all your browsers must support handling GZipped content as CloudFront won’t be able to serve an alternative (non-gzipped) version.

    Also, remember that CloudFront servers will cache the content, so if you change existing content you may not see the changes immediately. Normally the content you server through a CDN won’t change much anyway. I set the Expires and Cache-Control headers as well to ensure a long cache time in the browser, and then upload into a new ‘directory’ whenever content changes. Eg: store files as 20090318/file1.jpg 20090318/file2.jpg etc. and then if you change file1.jpg upload everything again as 20090319/file1.jpg, 20090319/file2.jpg, updating the HTML at the same time to point to the new ‘directory’.

    (Amazon S3 doesn’t really have directories, but you can pretend it does and many programs will manage this for you).

  39. Ryan Says:
    March 19th, 2009 at 6:14 am

    From Bangalore, India:

    PING d2onuwnge3cit8.cloudfront.net (208.67.216.132): 56 data bytes
    64 bytes from 208.67.216.132: icmp_seq=0 ttl=51 time=311.171 ms
    64 bytes from 208.67.216.132: icmp_seq=1 ttl=51 time=311.627 ms
    64 bytes from 208.67.216.132: icmp_seq=2 ttl=51 time=312.429 ms
    64 bytes from 208.67.216.132: icmp_seq=3 ttl=51 time=316.565 ms
    64 bytes from 208.67.216.132: icmp_seq=4 ttl=51 time=316.169 ms

    — d2onuwnge3cit8.cloudfront.net ping statistics —
    5 packets transmitted, 5 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 311.171/313.592/316.565/2.305 ms

  40. Francisco Says:
    March 21st, 2009 at 10:09 am

    From Vancouver BC, Canada
    ISP: Shaw Cable
    DNS Servers: OpenDNS.org
    (I noticed that all subnet masks submissions started with 216.137.x.x but not mine)

    Envoi d’une requête ‘ping’ sur d2onuwnge3cit8.cloudfront.net [67.215.65.132] ave
    c 32 octets de données :

    Réponse de 67.215.65.132 : octets=32 temps=179 ms TTL=58
    Réponse de 67.215.65.132 : octets=32 temps=179 ms TTL=58
    Réponse de 67.215.65.132 : octets=32 temps=181 ms TTL=58
    Réponse de 67.215.65.132 : octets=32 temps=178 ms TTL=58

    Statistiques Ping pour 67.215.65.132:
    Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
    Durée approximative des boucles en millisecondes :
    Minimum = 178ms, Maximum = 181ms, Moyenne = 179ms

  41. Lint Says:
    March 29th, 2009 at 5:21 am

    Host not found

  42. makaveli-mk Says:
    April 1st, 2009 at 2:35 am

    Also, does CloudFront support either ETAGs or Last-Modified header!

  43. Stephen Says:
    April 1st, 2009 at 6:41 pm

    Jim Thorpe, Pennsylvania (PenTeleData Network)

    $ ping images.groo.com
    ping: cannot resolve images.groo.com: Unknown host

  44. Bedava indir Says:
    April 5th, 2009 at 2:33 am

    You should host the images on this blog on CloudFront and see how it goes

  45. tatil Says:
    April 7th, 2009 at 8:09 am

    You should host the images on this blog on CloudFront and see how it goes

  46. Rene Glembotzky Says:
    April 7th, 2009 at 11:26 am

    From Hannover, Germany:

    PING d2onuwnge3cit8.sea4.cloudfront.net (216.137.35.222): 56 data bytes
    64 bytes from 216.137.35.222: icmp_seq=0 ttl=56 time=194.120 ms
    64 bytes from 216.137.35.222: icmp_seq=1 ttl=56 time=196.527 ms
    64 bytes from 216.137.35.222: icmp_seq=2 ttl=56 time=194.190 ms
    64 bytes from 216.137.35.222: icmp_seq=3 ttl=56 time=194.271 ms
    64 bytes from 216.137.35.222: icmp_seq=4 ttl=56 time=194.638 ms

  47. Brian Dickerson Says:
    April 8th, 2009 at 9:15 am

    Cool post! I’ll bookmark this page and wish to share it to all my friends and clients.

  48. rajakay Says:
    April 28th, 2009 at 2:46 pm

    You know? amazon’s recent acquisition? check it here..
    http://www.gizmosforgeeks.com/2009/04/28/amazoncom-acquires-lexcycle-maker-of-e-book-app-stanza/

  49. mike Says:
    April 30th, 2009 at 6:38 pm

    Nice to see the support for CloudFront.

Powered by WordPress. Pool theme by Borja Fernandez, modified by DreamHost.
Like WordPress? Consider attending WordCamp LA.
Entries and comments feeds. ^Top^