Hello all

I have been testing AWS Cloudfront and Limelight(Rackspace) for a week now and the results have left me surprised.

Firstly some background info :
I have a website that received 250,000 pageviews as day, has 10 million DB queries daily and runs on a really crappy server (Core2Duo with 2 GB RAM).
I am going to move my database to it's own server soon so I thought I might test a few CDN's to see what benefit I could get.
The main reason for using them was not to reduce the load on the main server, but just to test the loading time speeds that I could achieve.
I should also mention that my server is on the OVH network who are quite well known for their high ping times.

So, I made 3 copies of 2 pages (a light one and a heavy one) containing images, CSS and JS files and one page was assigned to each (my server, Cloudfront and Limelight).

Then I carried out speed tests at pingdom.com at 6 hour intervals for a week.

Light Page Results :
My Server - 0.8 seconds
Limelight - 1.2 seconds
Cloudfront - 1.5 seconds

Heavy Page results
My server - 2.2 seconds
Limelight - 3.5 seconds
Cloudfront - 5.5 seconds

During this whole time, my server was under a lot of pressure with CPU usage spiking to 100% at times.

These results have left me wondering about what the benefit of a CDN might be ? Are these results skewed because I used Pingdom ? Is there a better way to test site speeds ?

If pingdom servers are located in the USA, then Cloudfront and Limelight should have an advantage over mine because mine is in France. Actually, they should have an advantage in any other part of the world because OVH ping times are quite high even in Europe.

I even had an Akamai account set up but couldn't get it to work. It's too complicated for a monkey like me. Hopefully I'll be able to test it soon.

Also, another observation that I made was that Cloudfront is kinda the worst deal that you can get when it comes to CDN's. They charge for each GET request and that adds up pretty quick. Changing the TTL using cache-control headers is a pain (use the free version of Cloudberry Explorer - took me a long time to find that!) and even when I set the TTL to 365 days, it adds up pretty quick if you have a lot of new visitors(this is for my main website, by the way).

On the otherhand Limelight is quite good when it comes to costs. Even though bandwidth is $0.22/GB which is $0.05/GB more than Amazon (i think), you still save loads of money as GET requests are free. They charge for push, post and those types of requests but I don't use them as I use a CDN only for images, CSS and JS files. To compare, I was spending $2 a day with a 365 day TTL at cloudfront and am not even spending $0.10 a day with Limelight with a 1 hour TTL!

Also, most people say that AWS is easier to sign up and use but I would have to disagree with that as I have found Limelight to be way easier. With AWS, you still need to get external add-ons and software to do everything while with Limelight, you just login, upload, generate URL's and that's it. The only thing is that Rackspace calls you to confirm when you set up the account but that is real quick and takes only about 30 mins to get the call.

So anyways, these are the results of my test/comparison between CDN's and my own server. I would like to hear your experiences and also if you may have any suggestions on how these test could be carried out in a better way.

PS : In the above statements, Rackspace and Limelight are inter-changeable because Rackspace resells Limelight CDN.

Thanks for the info. :agree: I'm looking to become more educated on CDNs. I'm really curious why it would take longer to access the CDN versus your server, too.

- El Capitan

pingdom server located in EU should not serve as an excuse for the CDNs to fair poorer compared to OVH because cdn should have edge in EU too (limelight more specifically, AWS is depending on your subscription to EU).

was the test based on first pull or have you repeated the test several times?

how much traffic are you pushing with your website?

Why didn't you post your testing methodology? OBVIOUSLY your testing methodology is flawed. There is no possible way any sort of useful testing would give you those results.

pingdom server located in EU should not serve as an excuse for the CDNs to fair poorer compared to OVH because cdn should have edge in EU too (limelight more specifically, AWS is depending on your subscription to EU).

was the test based on first pull or have you repeated the test several times?

how much traffic are you pushing with your website?

The test was only the first pull but done every 6 hours for a week. My server hardly uses any bandwidth (~2 Mbps in a 100 Mbps line) but the CPU and RAM usage is very heavy (60-80%).

Also caching was enabled on Cloudfront and Limelight but not on my server. So if pingdom caches anything (which would make their test kinda useless), then the CDN's would have an advantage.


Why didn't you post your testing methodology? OBVIOUSLY your testing methodology is flawed. There is no possible way any sort of useful testing would give you those results.

Do you mean this ?


So, I made 3 copies of 2 pages (a light one and a heavy one) containing images, CSS and JS files and one page was assigned to each (my server, Cloudfront and Limelight).

Then I carried out speed tests at pingdom.com at 6 hour intervals for a week.

In reference to Pingdom, my site's front page (which is rather image heavy) dropped from 6.7 to 2.1 seconds on their ping test after making the switch to Akamai. I'm also on a US based server, located in SoftLayer's Washington DC datacenter.

http://static.exophase.net/rex/akamai-without.jpg
http://static.exophase.net/rex/akamai-with.jpg

Akamai is really easy to set up too. I used AWS before and it was ridiculously confusing in comparison. Never tried Limelight.

In reference to Pingdom, my site's front page (which is rather image heavy) dropped from 6.7 to 2.1 seconds on their ping test after making the switch to Akamai. I'm also on a US based server, located in SoftLayer's Washington DC datacenter.

http://static.exophase.net/rex/akamai-without.jpg
http://static.exophase.net/rex/akamai-with.jpg

Akamai is really easy to set up too. I used AWS before and it was ridiculously confusing in comparison. Never tried Limelight.

Akamai is one that I still have to try out.
With reference to my other tests, here are some examples :

Cloudfront : http://tools.pingdom.com/fpt/?url=http://d1xb23xc0cq648.cloudfront.net/cloudfront.html/&id=2349164

Limelight : http://tools.pingdom.com/fpt/?url=http://c0000238.cdn1.cloudfiles.rackspacecloud.com/limelight.html/&id=2349177

Highwinds : http://tools.pingdom.com/fpt/?url=http://hwcdn.net/b7y5m6m6/cds/highwinds.html/&id=2349174

And the winner, my server : http://tools.pingdom.com/fpt/?url=http://ns307262.ovh.net:8080/my.html/&id=2349181

Feel free to try and retry the tests. Also, the page that you will see will be blank but if you view the source, you will notice that each page has 1 CSS file, 1 GIF and 1 JS file in a 0 i-frame. Each page with its contents is completely hosted on the provider that is tested.

The amazing thing is that in these tests, my server takes 0.2 seconds to serve the page while the lowest among the CDN's is Cloudfront which takes 0.9 seconds.

Also, my server is used for a production site with 250,000+ pageviews daily and even then it manages to beat the CDN's.

Highwinds seems to have cheated in this test because when I used it on my site, it was timing out frequently :eek:

Akamai is one that I still have to try out.
With reference to my other tests, here are some examples :

Cloudfront : http://tools.pingdom.com/fpt/?url=http://d1xb23xc0cq648.cloudfront.net/cloudfront.html/&id=2349164

Limelight : http://tools.pingdom.com/fpt/?url=http://c0000238.cdn1.cloudfiles.rackspacecloud.com/limelight.html/&id=2349177

Highwinds : http://tools.pingdom.com/fpt/?url=http://hwcdn.net/b7y5m6m6/cds/highwinds.html/&id=2349174

And the winner, my server : http://tools.pingdom.com/fpt/?url=http://ns307262.ovh.net:8080/my.html/&id=2349181

Feel free to try and retry the tests. Also, the page that you will see will be blank but if you view the source, you will notice that each page has 1 CSS file, 1 GIF and 1 JS file in a 0 i-frame. Each page with its contents is completely hosted on the provider that is tested.

The amazing thing is that in these tests, my server takes 0.2 seconds to serve the page while the lowest among the CDN's is Cloudfront which takes 0.9 seconds.

Also, my server is used for a production site with 250,000+ pageviews daily and even then it manages to beat the CDN's.

Highwinds seems to have cheated in this test because when I used it on my site, it was timing out frequently :eek:

That is interesting, especially for such a small testing page. Although the fact that it is so small in size might be skewing the results. When serving files direct from your server (assuming same domain) there's no overhead from extra DNS lookups. Perhaps try sticking a few 100KB images on the test site and see if performance differs at all.

Here's an archived test with Akamai on my site -

http://tools.pingdom.com/default.asp?url=http://exophase.com/&id=2349674

2.9 seconds, and that's over 1MB of page data total. It varies from 2-4 seconds on average as there are external factors that impact the page speed (ads and such).

That is interesting, especially for such a small testing page. Although the fact that it is so small in size might be skewing the results. When serving files direct from your server (assuming same domain) there's no overhead from extra DNS lookups. Perhaps try sticking a few 100KB images on the test site and see if performance differs at all.

Here's an archived test with Akamai on my site -

http://tools.pingdom.com/default.asp?url=http://exophase.com/&id=2349674

2.9 seconds, and that's over 1MB of page data total. It varies from 2-4 seconds on average as there are external factors that impact the page speed (ads and such).

I don't think that there would be any delay due to DNS lookups because each page is independently served from a single domain. So for example, the cloudfront page is entirely hosted there so it will only take 1 DNS lookup.

Here are the testing results for a 7 mb page (it was actually bigger but pingdom stopped at 7 mb for all of them).

Limelight (15.7s) - http://tools.pingdom.com/fpt/?url=http://c0000238.cdn1.cloudfiles.rackspacecloud.com/limelight.html/&id=2353123

Highwinds (8.5s) - http://tools.pingdom.com/fpt/?url=http://cds010.lo1.hwcdn.net/b7y5m6m6/cds/highwinds.html/&id=2353130

Cloudfront (15.7s) - http://tools.pingdom.com/fpt/?url=http://d1xb23xc0cq648.cloudfront.net/cdntest/cloudfront.html/&id=2353152

Now, with my server I did 2 tests, one with nginx which I use to serve all static files and one with Apache.

My server nginx (4.5s) - http://tools.pingdom.com/fpt/?url=http://ns307262.ovh.net:8080/my.html/&id=2353226

My server apache (7.6s) - http://tools.pingdom.com/fpt/?url=http://ns307262.ovh.net/my2.html/&id=2353160

Notice the huge improvement when I use nignx to serve the same page from my server. Even then, no CDN was able to beat Apache. Highwinds again came out on top among the CDN's so I am thinking of giving it another chance.

So, in conclusion, my server running nginx takes half the time to serve the same page when compared to the CDN's tested. The closest was Highwinds which took almost double the time to serve the same page.

If anyone is looking to go for a CDN, I would suggest that you try nginx first to do the same job. If anyone wants step by step instructions on how this should be done, just let me know.

Just got a demo account for FDC's new CDN.

FDC CDN (25.1s) - http://tools.pingdom.com/fpt/?url=http://www.fdccdn.net/5417/fdc.html/&id=2353375

Note that this is a demo account so it might be on low priority wrt speeds. The prices are unbelievable though.

I use nginx as well, still noticed a huge difference after moving to a CDN. Remember the main reason to use a CDN is if you have visitors accessing your site from multiple regions. If a user from say Asia is getting poor download speeds from your site, nginx isn't going to help with that.

Give the tests at http://www.webpagetest.org a try, they aren't limited only to UK like Pingdom is.

Reminds me of the whole 'cloud' craze... I can almost guarantee a properly optimized VPS or dedicated server will yield faster loading times, sometimes MUCH faster, especially anything with Mysql involved.

But for a mainstream CDN and static files, this is a real eye opener.

Thanks for sharing.

I use nginx as well, still noticed a huge difference after moving to a CDN. Remember the main reason to use a CDN is if you have visitors accessing your site from multiple regions. If a user from say Asia is getting poor download speeds from your site, nginx isn't going to help with that.

Give the tests at http://www.webpagetest.org a try, they aren't limited only to UK like Pingdom is.

Right, so I ran some tests there by keeping the default options (1.5 Mbps AOL line in the USA).

Highwinds (79.114s) - http://www.webpagetest.org/result/100525_d365eef1ae986311a59c80fc4b8edbb4/

FDC (90.451s) - http://www.webpagetest.org/result/100525_f9f0cb312be5ba0fc0537a4caa9071ca/

Cloudfront (79.794) - http://www.webpagetest.org/result/100525_0e2829919b051e81ce111978b9957fcd/

Limelight (93.18) - http://www.webpagetest.org/result/100525_e35687787d2d406ec57e2ff0e32f8966/

My server on nginx (81.005s) - http://www.webpagetest.org/result/100525_acc07a16b33dc80214678ef847bffbc0/

My server on Apache (80.898s) - http://www.webpagetest.org/result/100525_2079176dd2d5c05b89e9d97111e71733/

So, when a test is done from the US, 2 CDN's beat my server but only by a negligible amount (2%). That doesn't really justify the prices that they charge. For example, on my OVH server, I pay $0.02/GB of transfer if I assume that I can achieve 15TB a month on a 100 Mbps server (my servers easily push more than that). Add to that the level of control that I get and also 6 TB of storage, then the CDN's have a long way to go to convince me to pay their prices. OVH has pretty bad transit in the US so at their prices, a 2% reduction in speed is more than acceptable, in my opinion.

I am sure that Akamai must be on an entirely different level but with the others I can only assume that the speed is a result of overselling ?

A point about Highwinds, even though it has better speed test results than other CDN's, HW uses some kind of redirection method to deliver files. If you do a pingdom test of an HW page, you will notice that a lot more URL's are visited before the content is actually loaded. In practice, I have noticed that on my website, only half the content loads when I use HW. I think that browsers might have some setting for redirection limits or something but this makes it completely useless for me. No, point in having only half the page load at blazing speeds and the visitor then pressing the back button.
Anyone else experience such a thing ?

Reminds me of the whole 'cloud' craze... I can almost guarantee a properly optimized VPS or dedicated server will yield faster loading times, sometimes MUCH faster, especially anything with Mysql involved.

But for a mainstream CDN and static files, this is a real eye opener.

Thanks for sharing.

Yup, tried Rackspace's cloud and disappointed with that too. I think that when you learn to optimize your own server, everything else seems like a compromise.
The only advantage of the cloud that I know of is the flexibility to expand when the need arises. One of the main selling point of clouds is saving costs, but they usually tend to cost a lot more per unit of resource than a dedicated server. I see it as a self-managed VPS with more flexibility and freedom.
So, I would much rather buy a dedicated server and spend the money on something like EasyDNS that has stuff like anycast and 5 sec TTL so that when the site grows, you just get a bigger server and move within 5 seconds (depending on the volume of data that you have). The only downtime would be the time it takes to move your database or something that updates frequently as everything else can be moved beforehand anyways.
You can also achieve near 100% uptime by using Easy DNS and having the failover service activated so even that seems like a weak selling point for a cloud.

Why didn't you post your testing methodology? OBVIOUSLY your testing methodology is flawed. There is no possible way any sort of useful testing would give you those results.

You seem to be quite certain of that. So, where is the flaw? And, why is is not possible that the OP got the results that he did?

Do you have a connection to the CDN industry?

BTW, pingdom uses multiple pops.

You seem to be quite certain of that. So, where is the flaw? And, why is is not possible that the OP got the results that he did?

Do you have a connection to the CDN industry?

BTW, pingdom uses multiple pops.

Hey, just noticed your sig. I really like the services that you provide (just so that it's not classified as advertising here, I mean the ones starting with B, E and N) and use them on a regular basis.
Keep up the good work!

Hey, just noticed your sig. I really like the services that you provide (just so that it's not classified as advertising here, I mean the ones starting with B, E and N) and use them on a regular basis.
Keep up the good work!

Thanks :D

Now, about your test results. First, they are completely believable. Coming from a third party with no particular bias is a point in their favour. Surely, pingdom did not test those pages any differently than the thousands of other pages they test. The tests would be consistent across any number of pages originating from any number of server origins.

The results that you got may be indicative of the overheads that are *inherent* in CDN usage.

A busy, but well tuned server, will almost always have the edge because it has less overhead. Don't forget that even if it looks busy, the statics are coming from cache and are a very small part of the workload.

On the other hand, the CDN frontend has the additional workload of fetching the static from an origin server, that is, your server. There is also some behind the scenes manipulation that is required that may be not obvious to someone who has not actually implemented a CDN.

The truth may be that CDN's are all about high volume and not necessarily speed, and, that factor conveniently, gets forgotten about when the buzzwords get thrown around. Where the "speed" factor comes in is when the origin server is completely bogged down. At that point, a bigger, or more server(s) might still be a better answer.

You seem to be quite certain of that. So, where is the flaw? And, why is is not possible that the OP got the results that he did?

Do you have a connection to the CDN industry?

BTW, pingdom uses multiple pops.

There are major flaws with the methodology here.

I assume since Pingdom doesn't actually offer a paid monitoring service for full page downloads (they only do basic HTTP or network port checks), the OP is just going to their free tools page (which does have a full page check) every 6 hours to run the test. If it's like their other checks, each check is run from a single location, not all of them. As you mentioned, they do have several locations for their monitoring checks, but on any given check, they're only using one of those, and that one randomly rotates around.

By doing this test only every 6 hours (and it could be getting hit from a different location every time, and therefore being pulled from a different CDN POP), there's also a very good chance that the CDN is pulling from the origin on every check. From the sounds of it, the only time the object is getting accessed is on the check every 6 hours, so there is good chance that the CDN has flushed the object from the cache at that location, and has to go back to the origin to fetch it, which obviously will increase the download time.

If the full page check is from a single location, it's probably from Sweden since that is their original location (and the traceroute tool also on that site is always from the monitoring location in Sweden), and hence not really a good test of CDN anyways. I've never seen a quality CDN, overall, perform slower on static elements being monitored from several different locations vs. a single location server, assuming the objects are being accessed frequently enough that you keep then in the CDN's caches as much as possible.

To the OP--use a different monitoring platform & methodology. You don't have to spend the big bucks for something like Keynote or Gomez, but you can do short term full page monitoring from several international locations using RedAlert or WebSitePulse, to name two off the top of my head. If you want to use Pingdom, a better test is to setup an HTTP check to a specific, static CSS or JS file on each CDN and your origin server, setup the monitoring interval to one minute to do your best to keep the object in the CDN's cache, and let that run for at least several days, if not longer. Then check the response time report and get back to us with the results.

I am sure that Akamai must be on an entirely different level but with the others I can only assume that the speed is a result of overselling ?

Could be the case, may be a combination of that and choosing non-optimal routes. I'm surprised at the Limelight results as they are often touted as the #2 competitor to Akamai.

Thanks :D

Now, about your test results. First, they are completely believable. Coming from a third party with no particular bias is a point in their favour. Surely, pingdom did not test those pages any differently than the thousands of other pages they test. The tests would be consistent across any number of pages originating from any number of server origins.

The results that you got may be indicative of the overheads that are *inherent* in CDN usage.

A busy, but well tuned server, will almost always have the edge because it has less overhead. Don't forget that even if it looks busy, the statics are coming from cache and are a very small part of the workload.

On the other hand, the CDN frontend has the additional workload of fetching the static from an origin server, that is, your server. There is also some behind the scenes manipulation that is required that may be not obvious to someone who has not actually implemented a CDN.

The truth may be that CDN's are all about high volume and not necessarily speed, and, that factor conveniently, gets forgotten about when the buzzwords get thrown around. Where the "speed" factor comes in is when the origin server is completely bogged down. At that point, a bigger, or more server(s) might still be a better answer.

I completely agree with you on the volume part. Maybe, under heavy traffic, the cracks in my server would start becoming more apparent. However, if this is a CDN's biggest advantage, then that would make it similar to a cloud as even the latter offers the ability to burst speeds when required.

Also, I think that CDN's will have an advantage when it comes to things like video streaming and serving larger files because files smaller than a few hundred mb could give inconclusive results.

I recently read an article about Google using Akamai for hosting the first Youtube live event or something that was expected to have a lot of viewers even though they have an extensive network themselves, maybe even bigger than Akamai. This would validate your point and mine to some extent.

There are major flaws with the methodology here.

I assume since Pingdom doesn't actually offer a paid monitoring service for full page downloads (they only do basic HTTP or network port checks), the OP is just going to their free tools page (which does have a full page check) every 6 hours to run the test. If it's like their other checks, each check is run from a single location, not all of them. As you mentioned, they do have several locations for their monitoring checks, but on any given check, they're only using one of those, and that one randomly rotates around.

By doing this test only every 6 hours (and it could be getting hit from a different location every time, and therefore being pulled from a different CDN POP), there's also a very good chance that the CDN is pulling from the origin on every check. From the sounds of it, the only time the object is getting accessed is on the check every 6 hours, so there is good chance that the CDN has flushed the object from the cache at that location, and has to go back to the origin to fetch it, which obviously will increase the download time.

If the full page check is from a single location, it's probably from Sweden since that is their original location (and the traceroute tool also on that site is always from the monitoring location in Sweden), and hence not really a good test of CDN anyways. I've never seen a quality CDN, overall, perform slower on static elements being monitored from several different locations vs. a single location server, assuming the objects are being accessed frequently enough that you keep then in the CDN's caches as much as possible.

To the OP--use a different monitoring platform & methodology. You don't have to spend the big bucks for something like Keynote or Gomez, but you can do short term full page monitoring from several international locations using RedAlert or WebSitePulse, to name two off the top of my head. If you want to use Pingdom, a better test is to setup an HTTP check to a specific, static CSS or JS file on each CDN and your origin server, setup the monitoring interval to one minute to do your best to keep the object in the CDN's cache, and let that run for at least several days, if not longer. Then check the response time report and get back to us with the results.

The CDN's I have used are not pulling from the origin anyways, as I have uploaded the files using FTP. So, I don't think that that can be touted as the reason for slow speeds. Also, I have performed the speed tests a second time using a US home connection, which gave a 2% speed increase when compared to OVH.

I was aware of the fact that objects accessed infrequently would not be cached by the CDN servers so I uploaded them directly, waited for around 6 hours for it to propagate through their servers (as they advise to do) and the speed tests were conducted after this.

Also, I would consider the US to be the stronghold for CDN's while OVH has has a pretty bad reputation for speeds there. So, a 2% speed increase to the US is pretty bad for the CDN's in my opinion.

I shall try to get the tests done from the other services that you mention. The pages that I have tested are still live (except maybe FDC as that was a demo account) so you could run some tests using them if you wish to.

<<snipped>>

I was aware of the fact that objects accessed infrequently would not be cached by the CDN servers so I uploaded them directly, waited for around 6 hours for it to propagate through their servers (as they advise to do) and the speed tests were conducted after this.

This is wrong. All you did was upload to another origin server. No real CDN (ie Akamai and Limelight) propagates anything to caching servers. It is requested and discarded after a certain amount of time and that's the end of it. You are very confused on how CDN's work.

This is wrong. All you did was upload to another origin server. No real CDN (ie Akamai and Limelight) propagates anything to caching servers. It is requested and discarded after a certain amount of time and that's the end of it. You are very confused on how CDN's work.

Yes, that is how they are meant to work. If so, then how would you explain this ?

10 runs from the same testing location to limelight and my server :

Limelight (78.704s) - http://www.webpagetest.org/result/100526_fddf075221f03807be51794a0118e913/

My server (80.876s) - http://www.webpagetest.org/result/100526_7782a7e5ecbe52163bebab407f7efb99/

Yes, that is how they are meant to work. If so, then how would you explain this ?

10 runs from the same testing location to limelight and my server :

Limelight (78.704s) - http://www.webpagetest.org/result/100526_fddf075221f03807be51794a0118e913/

My server (80.876s) - http://www.webpagetest.org/result/100526_7782a7e5ecbe52163bebab407f7efb99/

I wonder if you'd get similar results if you were to

1) Disable Etags
2) Set a future expires header

Here is header info for one part of your content, obtained at 14:45

Expires Wed, 26 May 2010 13:52:54 GMT
Cache-Control max-age=3600, public
Server Apache
Etag 2b5723a62db5bc2651aa5eb67d340485

Someone who knows more about Etags than me (I simply disable them) may be able to explain how Etags can be used in a CDN environment.

I wonder if you'd get similar results if you were to

1) Disable Etags
2) Set a future expires header

Here is header info for one part of your content, obtained at 14:45

Expires Wed, 26 May 2010 13:52:54 GMT
Cache-Control max-age=3600, public
Server Apache
Etag 2b5723a62db5bc2651aa5eb67d340485

Someone who knows more about Etags than me (I simply disable them) may be able to explain how Etags can be used in a CDN environment.

I thought that cache-control headers were meant for the users browser rather than the CDN caching servers. That is the header of the Limelight page which has a 1 hr expiry time but my server doesn't have one, so even if it is meant for the caching servers, wouldn't that put my server at a disadvantage ?
With Limelight, you can set a max cache-control of 24 hours while with Cloudfront, you can make it as long as you want.

Not sure about Etags, so if someone with more knowledge about them could chip in, that would be great.

I thought that cache-control headers were meant for the users browser rather than the CDN caching servers. That is the header of the Limelight page which has a 1 hr expiry time but my server doesn't have one, so even if it is meant for the caching servers, wouldn't that put my server at a disadvantage ?
With Limelight, you can set a max cache-control of 24 hours while with Cloudfront, you can make it as long as you want.

Not sure about Etags, so if someone with more knowledge about them could chip in, that would be great.

The thing to do is try it.

You may find your response times fall dramatically, *and* your server load goes down ... with or without involving a CDN.

The thing to do is try it.

You may find your response times fall dramatically, *and* your server load goes down ... with or without involving a CDN.

I do use a 365 day cache with nginx for my actual website. However, none for the tests here because I thought it might skew the results.

You are too stupid to warrant a response.
Is this meant to make all of us be impressed by your intelligence? If so, you're failing miserably. Please keep it on topic. If you have something useful to say, then reply with *information*. If not, there's no need to broadcast that you're infantile.

I could only imagine how successful Einstein would have been if, in attempting to prove the Theory of Relativity, he was like, "You're all too stupid to understand!" Would have gone over real well in the scientific community.

- El Capitan

By doing this test only every 6 hours (and it could be getting hit from a different location every time, and therefore being pulled from a different CDN POP), there's also a very good chance that the CDN is pulling from the origin on every check. From the sounds of it, the only time the object is getting accessed is on the check every 6 hours, so there is good chance that the CDN has flushed the object from the cache at that location, and has to go back to the origin to fetch it, which obviously will increase the download time.


Exactly. That is the Achilles Heel of CDN's in many applications. The content *must* be hot according to the heuristics applied by the provider. The problem is that the end user does not really care about whizbang technology, just the results. No rationalisation in the world is going to cut the ice if the real world experience is disappointing to the end user.


I've never seen a quality CDN, overall, perform slower on static elements being monitored from several different locations vs. a single location server, assuming the objects are being accessed frequently enough that you keep then in the CDN's caches as much as possible.


I have. The provider was Akamai. The client was Microsoft. So, no lack of size, money or influence in that combination. It was an open ticket for months until I stumbled along and diagnosed it for them. It got better, but was definitely not as fast as a standalone server. The files were hot, static, and big. Product iso images to be exact.

I thought that cache-control headers were meant for the users browser rather than the CDN caching servers. That is the header of the Limelight page which has a 1 hr expiry time but my server doesn't have one, so even if it is meant for the caching servers, wouldn't that put my server at a disadvantage ?
With Limelight, you can set a max cache-control of 24 hours while with Cloudfront, you can make it as long as you want.

Not sure about Etags, so if someone with more knowledge about them could chip in, that would be great.

That cache control header is telling the recipient to consider the file to be fresh for 1 hour. If your statics change rarely, then it is too short *and* drives up your usage costs.

ETAGS are notoriously difficult to implement properly in multi-machine scenarios. See the cacing links on mnot.org for the background.

I do use a 365 day cache with nginx for my actual website. However, none for the tests here because I thought it might skew the results.

Sure, but server-side caching is not the issue; it's browser-side caching.

In a sense, a CDN can act as an extension of a browser cache - both can reduce the number of requests made to the server. But it seems to me that can only happen if the cached content can be delivered without revalidating with the server.

Sure, server-side caching can reduce the ime for that revalidation; but the ideal is to eliminate the revalidating.

To avoid revalidating, the cache expires time must be in the future, not in the past. And Etags must be absent, or have values that do not force revalidation.

That cache control header is telling the recipient to consider the file to be fresh for 1 hour. If your statics change rarely, then it is too short *and* drives up your usage costs.

ETAGS are notoriously difficult to implement properly in multi-machine scenarios. See the cacing links on mnot.org for the background.

The 1 hour cache was set by me at Limelight as I am not really using it for anything else. For me real website, I like to use 365 days caches and when something is updated, I just change the file name and the browser downloads only that file.

Rackspace only allows a 24 hour maximum cache limit which is quite restrictive. They make their money only from the bandwidth hence they like to send the same content over and over again unlike amazon who are much more expensive even with a 365 day cache control when you are serving small files because they charge you for each request, even the ones that they reply with 304-not modified.

Sure, but server-side caching is not the issue; it's browser-side caching.

In a sense, a CDN can act as an extension of a browser cache - both can reduce the number of requests made to the server. But it seems to me that can only happen if the cached content can be delivered without revalidating with the server.

Sure, server-side caching can reduce the ime for that revalidation; but the ideal is to eliminate the revalidating.

To avoid revalidating, the cache expires time must be in the future, not in the past. And Etags must be absent, or have values that do not force revalidation.

Yeah, with nginx you can set the browser cache control header as well with one simple line which is quite nifty because it's much tougher to implement it with apache.

Reminds me of the whole 'cloud' craze... I can almost guarantee a properly optimized VPS or dedicated server will yield faster loading times, sometimes MUCH faster, especially anything with Mysql involved.

But for a mainstream CDN and static files, this is a real eye opener.

Thanks for sharing.
A cloud server that is appropriately setup shouldn't work any differently then an optimized VPS or Dedicated server. No matter what there is still a "server instance" running - either the cloud isn't adequate for the users needs, or it's not setup properly.


A point about Highwinds, even though it has better speed test results than other CDN's, HW uses some kind of redirection method to deliver files. If you do a pingdom test of an HW page, you will notice that a lot more URL's are visited before the content is actually loaded. In practice, I have noticed that on my website, only half the content loads when I use HW. I think that browsers might have some setting for redirection limits or something but this makes it completely useless for me. No, point in having only half the page load at blazing speeds and the visitor then pressing the back button.
Anyone else experience such a thing
Correct, even if you use a custom cname with highwinds, it is still going to be redirected to highwinds own hostname, causing some unnecessary delays. I assume this causes pingdom to have incorrect results with Highwinds speed tests. I definitely would recommend checking out Amazon & Akamai though; Akamai's distribution technology is far superior to anyone else I've ever investigated, but they know it so the cost is also a little bit higher.

Fabulous information, thanks a lot.

A cloud server that is appropriately setup shouldn't work any differently then an optimized VPS or Dedicated server. No matter what there is still a "server instance" running - either the cloud isn't adequate for the users needs, or it's not setup properly.


Correct, even if you use a custom cname with highwinds, it is still going to be redirected to highwinds own hostname, causing some unnecessary delays. I assume this causes pingdom to have incorrect results with Highwinds speed tests. I definitely would recommend checking out Amazon & Akamai though; Akamai's distribution technology is far superior to anyone else I've ever investigated, but they know it so the cost is also a little bit higher.

I tried Amazon in my tests above and it generally seemed to match Limelight in terms of speed (sometimes performing better) but the biggest turn off with them is the cost of get requests. If your website has a lot of new traffic (mine has 80% everyday) then Amazon is going to bankrupt you in no time.

I haven't tested Akamai yet because I am quite hesitant to spend the money on buying 1 TB of BW and then being disappointed as I have been with the others, as my website is managing fine without a CDN at the moment.

OVH are renting these pretty high end servers (with corei5 processors, 2*80GB SSD drives and 8 GB RAM) for £49.99+VAT. I am not sure if the price of Akamai is still being kept a secret but you can buy a few of these servers at the same price as 1 TB of Akamai bandwidth. At the moment, I would definitely choose loadbalancing using multiple servers over Akamai.

I wouldn't even consider it for a 1kb file if it's slow, but this is just me.

As for taking a couple of hours to make a file available after uploading does not necessarily happen because of having multiple locations, I think it's just rsync running every X hours. But again, you can never know. So the 2 hour thing is normal if you have to "upload" your files to the CDN server(s).

I am also surprised they don't offer Pull-From-Origin CDN service, I actually thought everyone provided that, until I realised that not so many do.

I know that MaxCDN have their own servers sitting at NOCs all over the US and in Europe. Also you never have to upload your files and use up storage unless you want to cache a file that is bigger than 10MB, otherwise you just need a Pull-from-origin Zone.

Not all CDN's offer an origin pull. I haven't seen one in Amazon or Rackspace (Limelight) and they are pretty big compared to FDC. Maybe Limelight offers it but Rackspace doesn't ?

The point I was trying to make before was that when it comes to larger files, it becomes unaffordable to pay such high rates to a CDN (at $0.10/GB, 1 TB of downloads will cost you $100) which is where FDC can be used. I am quite certain that FDC will focus on that market instead of branding their service as a conventional CDN.
They are and have always been a volume provider.

I think I read in FDC's CDN FAQ that they take a few hours to 'propogate' the data across multiple servers. They might be using rsync to acheive this, you never know. In any case, I think that they are well suited for the customers who want volume at the cost of reduced speed.

I shall post my results for maxCDN soon.

Not all CDN's offer an origin pull. I haven't seen one in Amazon or Rackspace (Limelight) and they are pretty big compared to FDC. Maybe Limelight offers it but Rackspace doesn't ?

The point I was trying to make before was that when it comes to larger files, it becomes unaffordable to pay such high rates to a CDN (at $0.10/GB, 1 TB of downloads will cost you $100) which is where FDC can be used. I am quite certain that FDC will focus on that market instead of branding their service as a conventional CDN.
They are and have always been a volume provider.

I think I read in FDC's CDN FAQ that they take a few hours to 'propogate' the data across multiple servers. They might be using rsync to acheive this, you never know. In any case, I think that they are well suited for the customers who want volume at the cost of reduced speed.

I shall post my results for maxCDN soon.

Ah-ha, I see what you mean now. You're right, this might be something where FDC comes handy with. I don't really use CDN for "huge" files, just for my websites and simple download, so costs were never an issue for me.

If you ever consider a CDN for your websites to deliver the simple stuff--fast, reliable, and affordable, I would recommend MaxCDN any day of the week :agree:

I tried Amazon in my tests above and it generally seemed to match Limelight in terms of speed (sometimes performing better) but the biggest turn off with them is the cost of get requests. If your website has a lot of new traffic (mine has 80% everyday) then Amazon is going to bankrupt you in no time.

I haven't tested Akamai yet because I am quite hesitant to spend the money on buying 1 TB of BW and then being disappointed as I have been with the others, as my website is managing fine without a CDN at the moment.

OVH are renting these pretty high end servers (with corei5 processors, 2*80GB SSD drives and 8 GB RAM) for £49.99+VAT. I am not sure if the price of Akamai is still being kept a secret but you can buy a few of these servers at the same price as 1 TB of Akamai bandwidth. At the moment, I would definitely choose loadbalancing using multiple servers over Akamai.

For global coverage Akamai is unbeatable - they have (last I checked) around 60,000 POPs worldwide. If you want to test a few files send them over and I can upload them to my origin server. Although I'm not sure what the performance will be like as others have pointed out, Akamai doesn't store static files at the edge for long unless they are accessed frequently. At any rate, moving to Akamai nearly halved our load times and made a noticeable difference in access speeds from other regions (UK, Germany, New Zealand).

But anyways, if latency doesn't matter as much then I'd agree that going the load balancing route is more economical.

For global coverage Akamai is unbeatable - they have (last I checked) around 60,000 POPs worldwide. If you want to test a few files send them over and I can upload them to my origin server. Although I'm not sure what the performance will be like as others have pointed out, Akamai doesn't store static files at the edge for long unless they are accessed frequently. At any rate, moving to Akamai nearly halved our load times and made a noticeable difference in access speeds from other regions (UK, Germany, New Zealand).

But anyways, if latency doesn't matter as much then I'd agree that going the load balancing route is more economical.

I honestly do not doubt the capabilities of Akamai. I think that they manage to maintain their quality by not overselling which I suspect is what reduces the speed with other providers.

If you wish to run a test, you can download the 10 mb test page from here (http://ns307262.ovh.net/my.html) and then try the multiple load test at webpagetest.org.

Exactly. That is the Achilles Heel of CDN's in many applications. The content *must* be hot according to the heuristics applied by the provider. The problem is that the end user does not really care about whizbang technology, just the results. No rationalisation in the world is going to cut the ice if the real world experience is disappointing to the end user.

I have. The provider was Akamai. The client was Microsoft. So, no lack of size, money or influence in that combination. It was an open ticket for months until I stumbled along and diagnosed it for them. It got better, but was definitely not as fast as a standalone server. The files were hot, static, and big. Product iso images to be exact.

I believe the discussion here revolved around small object delivery (which I'll admit, some CDNs do better than others), not large object delivery, which is a different usage case than the OP was looking at and trying to benchmark.

Obviously cache hit rates are a huge factor in performance (and some CDNs, such as MirrorImage, have marketed their much higher cache hit ratios vs. someone like Akamai, especially for smaller customers whose data is less likely to be accessed). Using full page monitoring from multiple locations is one way to help prime the CDN cache so to speak.

I've done plenty of performance tests using different CDNs for clients using a much more robust methodology than what the OP used (data which unfortunately I can't share), but there is plenty of information available about how various CDNs have significantly increased small object delivery. A simple Google search turned up the following:

http://chrismeller.com/2009/10/amazon-cloudfront-vs-rackspace-cloudfiles-cdn-performance
http://www.thebitsource.com/featured-posts/akamai%E2%80%99s-services-become-affordable-for-anyone-blazing-fast-web-site-performance-with-distribution-cloud/
http://www.paessler.com/blog/2009/08/12/prtg-7/making-our-website-faster-a-comparison-of-cloud-content-delivery-networks-cdns-with-cloud-storage-cloud-hosting-and-old-fashioned-hosting

This one uses a very similar methodology as the OP:

http://distractable.net/tech/appengine-resource-performance-why-you-need-cdn/

Note the closing comment, which leads me to believe that the OP doing the test only every 6 hours did lead to the object being invalidated in the closest CDN cache and hence needed to be fetched again every time the test was run.

One point of note is that initial test for the Rackspace CDN from Pingdom returned a much higher time for the image when I first requested the result, and this I expect was due to the need for the image to be moved to the closest server in the CDN for subsequent deliveries.

I believe the discussion here revolved around small object delivery (which I'll admit, some CDNs do better than others), not large object delivery, which is a different usage case than the OP was looking at and trying to benchmark.

Obviously cache hit rates are a huge factor in performance (and some CDNs, such as MirrorImage, have marketed their much higher cache hit ratios vs. someone like Akamai, especially for smaller customers whose data is less likely to be accessed). Using full page monitoring from multiple locations is one way to help prime the CDN cache so to speak.

I've done plenty of performance tests using different CDNs for clients using a much more robust methodology than what the OP used (data which unfortunately I can't share), but there is plenty of information available about how various CDNs have significantly increased small object delivery. A simple Google search turned up the following:

http://chrismeller.com/2009/10/amazon-cloudfront-vs-rackspace-cloudfiles-cdn-performance
http://www.thebitsource.com/featured-posts/akamai%E2%80%99s-services-become-affordable-for-anyone-blazing-fast-web-site-performance-with-distribution-cloud/
http://www.paessler.com/blog/2009/08/12/prtg-7/making-our-website-faster-a-comparison-of-cloud-content-delivery-networks-cdns-with-cloud-storage-cloud-hosting-and-old-fashioned-hosting

This one uses a very similar methodology as the OP:

http://distractable.net/tech/appengine-resource-performance-why-you-need-cdn/

Note the closing comment, which leads me to believe that the OP doing the test only every 6 hours did lead to the object being invalidated in the closest CDN cache and hence needed to be fetched again every time the test was run.

One point of note is that initial test for the Rackspace CDN from Pingdom returned a much higher time for the image when I first requested the result, and this I expect was due to the need for the image to be moved to the closest server in the CDN for subsequent deliveries.

Those are some interesting articles, thank you. I shall go through them soon.

Later in the thread, I also tested out the CDN's using webpagetest.org which loads a page multiple times simultaneously. Even in that CDN's only gave a 2% improvement in speed even though the tests were conducted from the USA where OVH has a very poor network.

Later in the thread, I also tested out the CDN's using webpagetest.org which loads a page multiple times simultaneously. Even in that CDN's only gave a 2% improvement in speed even though the tests were conducted from the USA where OVH has a very poor network.

I think the point is that to gain the most speed advantage from a CDN, the web pages have to be set up so the CDN can deliver them without referring back to the origin server.

I had the impression your tests did not make that possible - before satisfying any request, the CDN had to check with the origin server that the CDN's content was still up-to-date.

I think the point is that to gain the most speed advantage from a CDN, the web pages have to be set up so the CDN can deliver them without referring back to the origin server.

I had the impression your tests did not make that possible - before satisfying any request, the CDN had to check with the origin server that the CDN's content was still up-to-date.

Actually the origin server wasn't involved in any of my tests. I uploaded all the images and html to each CDN and then ran the tests. So, each page was independent of the other and with no origin pull involved.

Actually the origin server wasn't involved in any of my tests. I uploaded all the images and html to each CDN and then ran the tests. So, each page was independent of the other and with no origin pull involved.

Just because you're using an FTP or web based upload instead of an origin pull on your own server doesn't automagically push all your content to the edge/caching servers. It's essentially the CDN providing an origin instead of your own.

Just because you're using an FTP or web based upload instead of an origin pull on your own server doesn't automagically push all your content to the edge/caching servers. It's essentially the CDN providing an origin instead of your own.

Yes, that is true. That's the reason why I also did this test http://www.webhostingtalk.com/showpost.php?p=6815050&postcount=21

Also, all the pages are still active, so feel free to run your own tests on them if you want.

Tested your files on my Akamai account using the FIOS connection.

http://www.webpagetest.org/result/100602_6V5/

also ran benches using the same settings using your Limelight link as well as direct OVH server:

http://www.webpagetest.org/result/100602_6TE/
http://www.webpagetest.org/result/100602_6TW/

Akamai's lowest run was 12.108s, pretty significant win over the rest.

Tested your files on my Akamai account using the FIOS connection.

http://www.webpagetest.org/result/100602_6V5/

also ran benches using the same settings using your Limelight link as well as direct OVH server:

http://www.webpagetest.org/result/100602_6TE/
http://www.webpagetest.org/result/100602_6TW/

Akamai's lowest run was 12.108s, pretty significant win over the rest.

Excellent! Thank you very much.
This clearly proves that Akamai is a cut above the rest.

So I looked at your results and noticed the following.

1. Using Limelight through Rackspace CloudFiles uses an origin server in Dallas; that's pretty clear from the graphic on their site.

http://www.rackspacecloud.com/cloud_hosting_products/files/technology

2. The speed tests you ran were capped to simulate a 1.5M DSL line, which is going to minimize the impact of a CDN when simply downloading several large graphics. At that point, line throughput is going to be a limiting factor, not latency. When I ran the same tests using the 20M FIOS option from the same monitoring node in Virgina, I got a 17s load time from the Limelight page and 31s from the OVH page, so it was nearly half the loading time.

For global coverage Akamai is unbeatable - they have (last I checked) around 60,000 POPs worldwide. If you want to test a few files send them over and I can upload them to my origin server. Although I'm not sure what the performance will be like as others have pointed out, Akamai doesn't store static files at the edge for long unless they are accessed frequently. At any rate, moving to Akamai nearly halved our load times and made a noticeable difference in access speeds from other regions (UK, Germany, New Zealand).

But anyways, if latency doesn't matter as much then I'd agree that going the load balancing route is more economical.

The reason that AKM has so many machines is that their method includes colocating lots of smaller boxes in space donated by consumer isp's inside the isp perimeter. If everyone is hitting a popular file from some big site that's fine, but if someone goes after a less popular file, that's not so fine. Smaller disks means faster evictions.

So I looked at your results and noticed the following.

1. Using Limelight through Rackspace CloudFiles uses an origin server in Dallas; that's pretty clear from the graphic on their site.

http://www.rackspacecloud.com/cloud_hosting_products/files/technology

2. The speed tests you ran were capped to simulate a 1.5M DSL line, which is going to minimize the impact of a CDN when simply downloading several large graphics. At that point, line throughput is going to be a limiting factor, not latency. When I ran the same tests using the 20M FIOS option from the same monitoring node in Virgina, I got a 17s load time from the Limelight page and 31s from the OVH page, so it was nearly half the loading time.

I got similar results as you when I ran the tests with your settings. However, one thing that does come to mind is that not a large % of home users have a 20M line. I would imagine that a CDN should help those with smaller lines the most as the difference would be barely noticeable to those with a fast line anyways. I am talking about the delivery of small static files here.

Also, I need to admit that I do use a CDN myself for my Asian and US users because even though the difference may not be as noticeable, the issue with OVH is that outside Europe, files probably travel a longer distance to reach the user than a CDN, even if it queries the origin server each time. This is much more noticeable in Asia because the internet connections there are usually lower than western countries, so even a few seconds to us makes a large difference to those areas.

The reason that AKM has so many machines is that their method includes colocating lots of smaller boxes in space donated by consumer isp's inside the isp perimeter. If everyone is hitting a popular file from some big site that's fine, but if someone goes after a less popular file, that's not so fine. Smaller disks means faster evictions.

That sounds very logical. If I had a CDN, I would probably do the same just to show that I have more servers than anybody else.
I am sure Akamai isn't as crooked as me because their results from an earlier post do top the other CDN's.

Doesnt Akamai charge the ISPs and customers for the servers?
They certainly dont donate them!

This is probably one of the better CDN discussions here. I'll chime in with my recent experience. About 2-3 weeks ago I decided to give CDN's a shot because I have a high traffic forum delivering 20 million monthly page views but then I have one server dedicated to CSS/JS files and one for image serving. So these are 2 servers I have to not only pay for but also maintain. My site and servers are also subject to DDOS attacks.

I began checking out solutions beginning with AWS S3 and Cloudfront. For a few days I ran S3 and was unhappy with their per request fees. Would bring to be about 20-25 cents per GB. I then tried VPS.net which resells both Highwinds and Akamai. Highwinds enabled gzip compression for js and css files but from certain nodes there was noticable problems with delivery delays. I still have a ticket open with them trying to get it resolved.

Highwinds bandwidth was as cheap as 5 cents per GB. Very reasonable but pointless if there is lag on my site pages from css not loading.

Aware of the deal MaxCDN offered I decided to try them yesterday. So far I'm super happy. I will say their control panel doesn't work properly in IE8 or Opera but in Firefox it's fine. Delivery has been very fast in both push and pull zones. Setup and control seem great. Price is about 10 cents per GB but they have an introductory deal of 1TB for $40 that I couldn't pass up.

My CSS/JS delivery is maybe 150GB a month but my image delivery is 300GB a month. My issues is that it's milions of hits per day.

So unless Highwinds fixes their Pheonix servers I'll stick with MaxCDN.

For some CDNs can serve the purpose of worry free content delivery. Yes I know I can rent servers cheaper and even maybe VPS's will work but the CDN allows me a worry free solution. The split second differences in delivery aren't going to matter in the long run. I'm happy to pay $20-$50 a month for CDN on my static content so I can focus on my database, firewall, and dynamic delivery.

This is probably one of the better CDN discussions here. I'll chime in with my recent experience. About 2-3 weeks ago I decided to give CDN's a shot because I have a high traffic forum delivering 20 million monthly page views but then I have one server dedicated to CSS/JS files and one for image serving. So these are 2 servers I have to not only pay for but also maintain. My site and servers are also subject to DDOS attacks.

I began checking out solutions beginning with AWS S3 and Cloudfront. For a few days I ran S3 and was unhappy with their per request fees. Would bring to be about 20-25 cents per GB. I then tried VPS.net which resells both Highwinds and Akamai. Highwinds enabled gzip compression for js and css files but from certain nodes there was noticable problems with delivery delays. I still have a ticket open with them trying to get it resolved.

Highwinds bandwidth was as cheap as 5 cents per GB. Very reasonable but pointless if there is lag on my site pages from css not loading.

Aware of the deal MaxCDN offered I decided to try them yesterday. So far I'm super happy. I will say their control panel doesn't work properly in IE8 or Opera but in Firefox it's fine. Delivery has been very fast in both push and pull zones. Setup and control seem great. Price is about 10 cents per GB but they have an introductory deal of 1TB for $40 that I couldn't pass up.

My CSS/JS delivery is maybe 150GB a month but my image delivery is 300GB a month. My issues is that it's milions of hits per day.

So unless Highwinds fixes their Pheonix servers I'll stick with MaxCDN.

For some CDNs can serve the purpose of worry free content delivery. Yes I know I can rent servers cheaper and even maybe VPS's will work but the CDN allows me a worry free solution. The split second differences in delivery aren't going to matter in the long run. I'm happy to pay $20-$50 a month for CDN on my static content so I can focus on my database, firewall, and dynamic delivery.

Thanks for sharing your experience. I have switched from Rackspace to VPS.net at the moment. I am not using their CDN offerings but have created a virtual machine with nginx and serve static files from there.

Since moving, some of my heaviest pages with ads load in 2 seconds instead of the 4 seconds it took previously with Rackspace. Also with my VPS serving static files, I get a lot more control like setting the cache control header to 365 days. Even after setting such a long expiry date, I currently use around 150GB of BW a day to just serve CSS and image files.
It also works out a lot cheaper (around $0.06/GB) and manages to beat all the CDN's I know of in terms of price and speed. I haven't tried Akamai yet, so maybe that outperforms most other delivery methods/services as users in previous posts have mentioned.

I recieved a response today from Highwinds about their server problems. They claim a server had a problem but it's now resolved. I can't say I'm happy that I have to report the problem and they don't actively monitor their own servers well enough to notice that much lag.

MaxCDN has been flawless but I'll wait a couple weeks and try Highwinds again. Unfortunately after a week of it being okay I prepaid $300 which is like a year of CDN for me. I may ask if they can convert that to either VPS or Akamai if Highwinds tests poorly for me again.

I think it's smart having more than one CDN as I've setup my site to change CDN delivery with one setting. If one lags then I can quick switch.

I recieved a response today from Highwinds about their server problems. They claim a server had a problem but it's now resolved. I can't say I'm happy that I have to report the problem and they don't actively monitor their own servers well enough to notice that much lag.

MaxCDN has been flawless but I'll wait a couple weeks and try Highwinds again. Unfortunately after a week of it being okay I prepaid $300 which is like a year of CDN for me. I may ask if they can convert that to either VPS or Akamai if Highwinds tests poorly for me again.

I think it's smart having more than one CDN as I've setup my site to change CDN delivery with one setting. If one lags then I can quick switch.

VPS.net should be able to convert it for you as they did it for me once, only problem is that it took me 2 weeks to have it done. Really slow support but I didn't mind as the issue wasn't critical.

As for switching between CDN's, doing it manually might be a tedious task. How about setting your script to accept URL parameters on which CDN to use like http://abcd.com/?cdn=max and similar. Then you can get an account at pingdom and add all your different CDN url's there. Then you use their API to let your server know which page has the lowest average ping time every x minutes and accordingly your server switches to that CDN thus ensuring fastest load times. I am very bad at programming but for someone who is even moderately good at it, it should be easy to implement I think.

As for switching between CDN's, doing it manually might be a tedious task.

I have my site setup with one setting to change. Very easy.

I have my site setup with one setting to change. Very easy.

Sorry, what I meant to say was that monitoring was the tougher task.

I'm on the site constantly. It's a 4 million post forum. So anything like lag member are quick to report.

I'm on the site constantly. It's a 4 million post forum. So anything like lag member are quick to report.

Yup, I forgot how much admin work a forum involves. Makes me shudder just at the thought of it :)

I did my own CDN testing this week (using MaxCDN as my first trial) and was happy with the results.

I created a wordpress flash games site, which is really heavy and slow, lots of images and heavy content. I thought that would be a good test.

The index page load decreased by about 4-5 seconds (using pingdom) when I started pulling the images and files via maxcdn. Actually, pingdowm helped me spot a few errors that caused the site to load in 17 seconds originally! I also found later in trials with another site, the load time could be decreased further by adding more cnames cdn01, cdn02, cdn03 and splitting the files across the 3 subdomains (works well for concurrent download of multiple files using different urls for the same file). Now I could get this site to load much quicker, but a heavy defaultish wordpress site it is, benefited a lot with cdn.

Anyway, tools like pingdom are good, but you need to make sure when testing things that your target audience, will get the expected results as well. ISP's differ in who they peer with and if your ISP doesn't peer with a particular provider, then you won't see full benefit of hosting files on cdn. Example, I work for an NZ ISP who peers with limelight, anything on limelights cdn for me, gets pulled via sydney, which is only 26ms away. Now another ISP (Telecom Xtra) do not peer with limelight, and the files get pulled via LA instead, as that's Limelights nearest peering place. That's a big difference, over 120ms more to get to the files right away. Now pingdom, I haven't checked to see who they host with, but unless they have machines on networks with dsl subscribers, that the ISP peers with your cdn, then you won't see totally accurate results.

Anyway, I have attached a couple of screen shots, showing the success story for my test site and maxcdn. I aim to test out limelight and others in a similar fashion for this site.

17144

17146

Pingdom's tools are only from a single location, their first monitoring location in Stockholm, Sweden. For a U.S. based site, with the bulk of their visitors in the U.S., it's obviously not particularly representative. I don't think they simulate an ASDL or whatever connection; I believe this is their ASN info for that location:

http://www.robtex.com/as/as16150.html#graph

I don't think CDNs are for everybody and for all cases. Internet is so dynamic with constantly changing capacity of lines, number of peerings, static vs dynamic pages, development of connections in third world countries, that CDNs importance is changing all the time. I am sure Akamai was much more advantageous 10 years ago vs now. I am sure classical CDNs have problems with live streaming services, including new types of streaming. I am sure optional devices on network, SSDs and software optimization could make much bigger impact on the overall user experience, then using CDN vs not using CDN.

Our monitoring systems are showing sometimes no optimization 2000 ms, with optimization 127 ms latency to some third world countries. I don't think CDN would help for highly dynamic site, especially if images are dynamically generated or again we are talking about live A/V stream.

I am not against CDNs, but I think cases when you really need CDN have to be calculated based on the needs - kind of difficult task for an average site maintainer. So why sometimes CDN actually could degrade performance of the website.

Regarding bandwidth prices at OVH - low? See how much are they charging once you'll go above 15 GB on "unmetered" 100 Mb/s line - you can't compare prices of "unmetered" (with 15 GB limit ! :) on 100 Mb/s port) dedicated plans with metered bandwidth services. Sorry, you can, but they are kind of incomparable.

I do not know of any OVH server that comes with a 15 gb limit. Their minimum limit is 5 TB if you take normal transit priority and unlimited with low transit priority for the low end servers and that comes to around $0.02/GB (the prices will differ according to server specs) for the first option.

I have been using them for a long time now and have never had to pay any charges for crossing 15 GB of BW usage a month. On some of my servers, I have also used 25 TB a month (on low transit priority) without any issues.

I don't think CDNs are for everybody and for all cases. Internet is so dynamic with constantly changing capacity of lines, number of peerings, static vs dynamic pages, development of connections in third world countries, that CDNs importance is changing all the time. I am sure Akamai was much more advantageous 10 years ago vs now. I am sure classical CDNs have problems with live streaming services, including new types of streaming. I am sure optional devices on network, SSDs and software optimization could make much bigger impact on the overall user experience, then using CDN vs not using CDN.

Our monitoring systems are showing sometimes no optimization 2000 ms, with optimization 127 ms latency to some third world countries. I don't think CDN would help for highly dynamic site, especially if images are dynamically generated or again we are talking about live A/V stream.

I am not against CDNs, but I think cases when you really need CDN have to be calculated based on the needs - kind of difficult task for an average site maintainer. So why sometimes CDN actually could degrade performance of the website.

Regarding bandwidth prices at OVH - low? See how much are they charging once you'll go above 15 GB on "unmetered" 100 Mb/s line - you can't compare prices of "unmetered" (with 15 GB limit ! :) on 100 Mb/s port) dedicated plans with metered bandwidth services. Sorry, you can, but they are kind of incomparable.

it's a great

I noticed a lot of the tests in this topic are also using CSS and JS via a CDN.

Some (or perhaps most? ) CDNs don't support gzip compression. Result: downloading from your own gzip enabled server could be faster then downloading from a CDN because the filesize is on your own server is much smaller.

So if someone is going to test a CDN then first make sure the CDN supports gzip. If it does then use the CDN for CSS and JS files. If not then use your own gzip enabled server. Then you can test. (and ofcourse also test CSS and JS on a CDN when it does not support gzip and compare it with your own server)

Does anyone know which CDNs support gzip?

Well, CDN companies who use our software supports gzip by default :D

I know MaxCDN supports gzip. Highwinds does as well but you have to ask them to enable it for you.

I was using HWCDN for a few weeks. It was terrible. Just didn't work out well. I had site visitors complaining constantly about pages not loading.

I've since switched to MaxCDN and it's been great.

btw I'm pretty sure Amazon AWS does not support gzip. At least not that I could tell. I dropped using them since they charge a per request fee (penny per 10k). It's not that expensive but I serve millions of small files per month and the request fee was more than bandwidth for me.

I'm only using about 100GB a month.

MaxCDN actually has a great 1TB special for only $40 a coupon is floating around too. So I now have almost a year of CDN for next to nothing.

I noticed a lot of the tests in this topic are also using CSS and JS via a CDN.

Some (or perhaps most? ) CDNs don't support gzip compression. Result: downloading from your own gzip enabled server could be faster then downloading from a CDN because the filesize is on your own server is much smaller.

So if someone is going to test a CDN then first make sure the CDN supports gzip. If it does then use the CDN for CSS and JS files. If not then use your own gzip enabled server. Then you can test. (and ofcourse also test CSS and JS on a CDN when it does not support gzip and compare it with your own server)

Does anyone know which CDNs support gzip?

Akamai does.. I'm pretty sure most of the big players in this market do.

Thanks...

Since yesterday I have a testaccount for Edgecast (also supports gzip) via a reseller (Speedyrails, filled in the form and two hours later my testaccount was ready to use). So I'm going to test this in the upcoming days.

I would also like to test Akamai. Yesterday I have asked for a quote via vps.net. No reply yet. Not sure if they also offer a testaccount.

Perhaps it is already mentioned in this topic but on the following page you can read some CDN testresults:
till.klampaeckel.de/blog/archives/100-Shopping-for-a-CDN.html

In the test:
Akamai
CacheFly
Cloudfront
EdgeCast (large files)
EdgeCast (small files)
Limelight
Amazon S3

Hey Guys,
I'm posting from New Zealand and I think I may be able to offer an interesting perspective at least from my country. In NZ, it is very common for people to have very fast internet connections to sources hosted within the country - we call this "national" connectivity. The cost of transferring data from overseas e.g. USA or Europe is infinitely higher and thus speeds are much slower. For example we pay $70US a month for unlimited 1gbps of national (within NZ) traffic and $200US a month for 1mbps of international (outside of NZ traffic). Thus we only have 1mbps to most websites which makes them really slow to load.

Luckily there is an Akamai cache connected to the main peering exchange here so we get lots of content at very high speed. This situation is probably the case in many other parts of the world, including China, Australia etc.

where can you get that 1gps local bandwidth for $70 here?

where can you get that 1gps local bandwidth for $70 here?

Virtually every colo provider will give you at least 100mbps unmetered NZ. I know Sitehost provide 1gbps port speed and have up to that speed into the APE. Obviously Telstra/Telecom may be a little slower but I don't truely teach them as local due to their monopolistic peering practices which prices them more international. In any case, most providers still will count them as national but you simply may not get the same speed as a free peer.

i looked sitehost their website it doesn't say they provide 1gps local bandwidth it just says free local bandwidth. It also states 10GB int'l bandwidth included for $150/mo+GST colo fee.

Well they have 1gbps into the APE and they give your server a 1gbbps port - I use them and I have seen some really high speeds, the limitation has mainly been with the data source for testing speed but I get 250mbps+ on Citylink.

We are moving to Orcon & getting a half rack. They are providing only 2x 100mbps ports and we are paying for 1mbps international connection.

hows the on-site support like? how much orcon charge for half rack colo? our equipments are currently at unleash while i'm very happy with service and excellent up-time bandwidth cost is too steep and i'm looking at alternative for local expansion, if you are free to have a chat about it please contact me at rg(at)quickweb.co.nz i just have some questions :)