/clientscripts over to Amazon S3/Cloudfront?

[imported_silkroad]

We have moved most of our static images over to Amazon Cloudfront/S3 content delivery network (CDN) over the past few months with good results.

Now, I am considering moving all the vB clientside Javascript in the /clientscript directory over to Cloudfront as well.

Anyone else using a CDN for the JS in the /clientscript directory?

Any issues other than keeping in sync with updates anyone can think of?

[R1lover]

Why would you want to do this?

[imported_silkroad]

Originally Posted by R1lover

Why would you want to do this?

Because these (clientside) scripts account for (approx) 1/3 of the traffic, so moving them to a CDN will reduce the load on the server and also increase performance (just as it did when we moved most of all the static images).

[kmike]

You should consider adding "Expires" HTTP header to .js files, so the user browsers won't have to re-check these files for updates on every page load. And by the way, the same could be done for the static images.

For the record, .js files (with the Expires header) account for 0.9% of our bandwidth usage. Forum images take another 1.20%.

[R1lover]

I would think putting your money in a better setup/server is better then putting your money into another host, in this case the cloud setup.

I agree that static images and .js have little to no impact on any of my servers or sites.

There is more to be had with a good server and proper setup.

[imported_silkroad]

Originally Posted by R1lover

I would think putting your money in a better setup/server is better then putting your money into another host, in this case the cloud setup.

I agree that static images and .js have little to no impact on any of my servers or sites.

There is more to be had with a good server and proper setup.

We have a good server and have run benchmarks with Amazon S3/CF. You cannot get the same global performance from a single server or local cluster than you can with a global CDN.

While your "opinion" is valuable. It is also incorrect because we have alread run the performance numbers and know the gain realized from the global Amazon CDN.

OBTW, Amazon CloudFront services are not "another host", so it seems you enjoy an "opinion" about something you do not understand. CloudFront is a Content Delivery Network with (seven I think, at last count) global geographic locations. It is not a hosting solutions.

We run over 500 metrics on our configuration and know the performance better than an uninformed third party who, frankly speaking, is just "hip shooting".

In fact, in the vBSEO forum, there are a number of users, like us, who server static content off the main server. Some use other hosts, others, like us, use a global CDN.

Sorry to be so direct. Facts are facts.

Cheers.

[R1lover]

Not wanting to argue here, but if they are storing your images and then serving them and you are paying for this service, then in fact they are a host... lol

The only benifit I an see is one that you mentioned, being globally located for faster service to people on the other side of the world.

Other then that you are still paying for something you should be able to do yourself.

This all changes as the size of the forum has a large impact on these things as well, but since you didn't mentione this I went with what the aerage user would need and this service for the average user is useless imo.

[imported_silkroad]

Let's not argue, because you are shooting from the hip and will just keep shooting yourself in the foot my friend :-) I posted here, not do debate performance, but to look for configuration issues related to vBulletin, but I was able to work with the folks on the vBSEO board to fine tune all those issues.

Here are some published data related to CF/S3 performance, you can review yourself.

Amazon CloudFront / S3 Small Object Test Result

Huge client side gains for using CloudFront (across the board), some as high as 95% improvement.

On a different note, related to server side apache GETs (which effects apache workers, load, etc.)

As I posted earlier in this ill-fated thread, our /clientscript traffic accounted for 30% of all our GET requests (before I moved them to S3/CF yesterday). (The static gifs are mostly gone off the server and were already served from CF globally).

Regarding the reason I posted here, I was not looking for a performance discussion, as I know the performance intimately, serving millions of PVs per month.

We are all set now..... We had a very useful discussion over at vBSEO on this.

Cheers.

[motowebmaster]

I would be interested in the outcome of this strategy.

[imported_silkroad]

Originally Posted by motowebmaster

I would be interested in the outcome of this strategy.

The basic outcome has already been published:

Amazon CloudFront / S3 Small Object Test Result

I can confirm that moving the /clientscript also results in better server performance, especially if you have a lot of .js code (from mods, plugins, etc.).

Globally, pulling static objects like images and Javascript results in faster response time for end users (unless they are next to the server, of course, see results above), decreased Apache workers, decreased bandwidth (out from the main server, increased at CF/S3 of course) and a decrease in load average (load results depend on a number of factors and is not easily qualified).

Please note that vB/Jelsoft uses the same strategy (for a long time) in the Server Settings and Optimization Options:

Use Remote YUI
YUI (Yahoo! User Interface Library) script files are hosted locally on your server, you may however have them served from Yahoo's own servers, saving you some bandwidth and potentially decreasing load times.

So, you can see that Jelsoft/vB already use this strategy for the YUI scripts to increase performance, etc. Using a global CDN (like Amazon S3/CF, Limelight, etc). for static content (images, clientside scripts, etc) is the same strategy (but on a larger scale).

:-) Maybe we can convince Jelsoft to serve their scripts in S3/CF and permit all vB customers to pull from the global CDN as part of the license :-)