/clientscripts over to Amazon S3/Cloudfront?

[imported_silkroad]

I have been "overly vocal" lately about vBulletin not being "CDN friendly" .... It take a lot of detective work to track down all the hard coded paths to static files.

In addition, if you run vBSEO, vBSEO hard codes a "/" into some of their image rewrites so even when you change a basic vBSEO config var (not all, but one or two) you end up with "/http://... blah blah... "

It is a lot of work to move vB static object to a CDN, so much is hard coded without phrasing or style vars. Some are hard coded in the dB. Some plugins are even worse. I could not get a 100% solution, but I'm happy with the 99% solution for now.

[tpearl5]

Yeh, I've run into many similar problems. I really wish it was easier to change over attachments.

[imported_silkroad]

I did not move attachments over yet ... same problem, code not CDN friendly.

[john2k]

The main goal with CDNs, the way I understand it, is to reduce network latency by reducing the distance between the end user and the content.

CDNs reduce the distance over the wires that the data needs to travel, reduces the number of network hops and helps to avoid your data needing to traverse over congested network equipment (or the chance that it might hit congested equipment on the networks that are skipped).

Reducing latency is very helpful for videos and especially streaming media, which many of the CDN networks like to focus on (more bandwidth income for them with video).

Cloud hosting is defined differently by many hosts. The inconsistency makes it a bit difficult to compare. Not all clouds are the same and not all clouds are also content delivery networks.

[imported_silkroad]

Originally Posted by john2k

The main goal with CDNs, the way I understand it, is to reduce network latency by reducing the distance between the end us er and the content..

Actually that is only one "main goal" of a CDN.

We find that using a CDN also significantly reduces the load on the primary server. Here as some example stats from our CDN provider for our site, and this is off peak:

Last 30 Minutes Data Trans: 578.03 MB 
Last 30 Minutes Total Hits: 106,167 
Last 30 Minutes Hits/sec: 59 

Last Hour Data Trans: 1.14 GB 
Last Hour Total Hits: 214,881 
Last Hour Hits/sec: 60 

Last Day Data Trans: 19.73 GB 
Last Day Total Hits: 3,739,688 
Last Day Hits/sec: 43 

Last Week Data Trans: 108.18 GB 
Last Week Total Hits: 21,048,256 
Last Week Hits/sec: 35

Taking 43 hits per second off any server improves performance. So, CDNs provide both better delivery globally, and better origin server performance.

Also, there is a huge difference between "the theory of using a CDN" and actually using one. I find it a more-than-funny having folks who do not use a CDN to be explaining to me, using a CDN that serve over 20 million objects a week, the benefits of a CDN.

[kmike]

Originally Posted by imported_silkroad

Taking 43 hits per second off any server improves performance.

Just a quick note that 43 hits per second for a seldom changing and relatively small (a few hundred of megabytes in total) static content is nothing for the modern multiplexing web servers such as nginx or lighttpd. They are able to serve tens of thousands concurrent connections, effectively solving the C10K problem. This kind of load may pose a problem for Apache which isn't really suitable for the static content serving, but a few hundred hits per second for the static content residing in the OS cache (so there is no disk I/O) is peanuts for nginx.

Not trying to downplay your accomplishment, just pointing out there is another way to reduce server load - by switching to the more modern web server software.

[imported_silkroad]

Originally Posted by kmike

Not trying to downplay your accomplishment, just pointing out there is another way to reduce server load - by switching to the more modern web server software.

No offense taken, don't worry. So please do not take offense to my direct reply.

First of all, you are replying, making numerous assumptions that might be relevant to your site, but not relevant to another site. So please don't be offended, but when I read your reply it seems you are not talking at all to me and our configuration requirements, but are just talking, to make a statement about web server optimization. Why?

Because you are simply promoting a few high performance web servers without considering the bigger picture. For example, did you consider that we may have solid reasons running Apache2 and that make extensive use of mod_rewrite and mod_geoip and other Apache mods?

Did you consider there are real costs of porting an entire site over to another web server that may or may not have the feature we need versus a few dollars a month for CDN services? A discussion about performance trade-offs without considering costs and other trade-offs is simply academic and generally meaningless.

Furthermore, off-loading static content to a CDN reduces the load on any web server. Even if you run nginx or lighttpd (which have have looked at and frankly do not like them) or Apache or anything under the sun, you will gain performance. Less hits means less load on any web server, independent and orthogonal to other server optimizations.

So, my impression to your post, nothing personal, is that you want to talk past me and make technical statements about web server software without considering the bigger picture (O&M, cost-benefit, features, etc.) of our requirements. The bottom line is that if we wanted to run nginx or lighttpd we would be running them. They are not "state secrets" ROTFL. We prefer Apache server for many reasons and yes, we have looked at both nginx and lighttpd. We prefer Apache2.

And.... as I said earlier, it is pointless (and also technically incorrect) for anyone to argue that moving static content off a server to a CDN is good for Apache but not for nginx or lighttpd. It is good for any configuration. The discussion gets muddled when we are discussing apples and someone wants to talk pasta and wheat bread.

So, if you intend to reply to me about CDN benefits and tradeoffs, then please do so. However, if you just want to talk and advocate your favorite web server technology or optimization strategy, that is a difference story. Go ahead, advocate nginx or lighttpd, but that has little or nothing do to with the discussion of the benefits of a CDN. They are orthogonal discussions.

CDNs benefit all configurations and software, modern or antique from the days of iron Gone-Daddy-Gone. Discussions about web server performance optimization, while interesting, are orthogonal to a discussion on the various benefits of moving static content off the server, any server, to a CDN.

Cheers.

[john2k]

Originally Posted by imported_silkroad

Actually that is only one "main goal" of a CDN.

I agree from an end-user standpoint but was commenting in regards to the business need that most CDNs appear to be working to solve. All of them seem to be focused on bringing the content as close to the end-user as possible in order to reduce network latency. Running fast non-overloaded equipment is pretty much a necessity for them, however there are times when CDN equipment does get overloaded.

They could easily solve the load problem by having a huge cluster of servers & equipment in a single datacenter, but that does not solve the network problem where latency can cause stuttering with streaming media, etc. This is why the CDNs have as many edge locations as possible, in order to address the network issues.

For example, you could host your images anywhere else regardless of quality and that would still reduce the load on your webserver. VPS, another dedicated server or even a clustered file hosting provider such as http://www.blueturbo.com/file-hosting.php Blue Turbo solves the server load issue, but not the network issue as they run a cluster from a single datacenter. The network issues generally are not nearly as significant for images as they are for video, though, which is why Blue Turbo makes sense for many (I considered using them, but I do not).

To see the real power and benefits of a CDN, we can use Highwinds for an example. They streamed coverage of the presidential inauguration to a peak of 625,000 concurrent visitors using 310Gbps bandwidth. They could have done this from a single datacenter, but the viewing would not have been optimal for some viewers due to the network issue.

In my opinion, that's what CDNs are really being created for. But, I use a CDN for basically the same reason as you. Last month I offloaded just under 50 million image views to a CDN. The sole reason that I began using a CDN wasn't about the network latency benefit but was to reduce load on my webserver until my new server is built & colocated. Even after my new server is online I might keep images running from a CDN but am not certain about that just yet.

[imported_silkroad]

Originally Posted by john2k

I use a CDN for basically the same reason as you. Last month I offloaded just under 50 million image views to a CDN. The sole reason that I began using a CDN wasn't about the network latency benefit but was to reduce load on my webserver until my new server is built & colocated. Even after my new server is online I might keep images running from a CDN but am not certain about that just yet.

Actually we use a CDN for a number of reasons (not one reason).

• Global delivery from the CDN network (network performance, end user experience globally)
• Deliver static content from "other than" origin server (server performance, user experience globally) reducing load (CPU, memory, and device IO) on origin-server.
• Network robustness, more secure, content delivered from many nodes globally, not one node or a geographic cluster.

When I started this thread I was using Amazon CloudFront, but now we have ported to SimpleCDN. CloudFront performance is much better than SimpleCDN, but SimpleCDN is much, much cheaper, the near-real time stats are better, cache control is better and getting non-CDN-cached files from the origin server is much better than the upload to S3 AWS model.

OBTW, SimpleCDN mirror bucket service is now cheaper (and must less work) than most budget web hosting based solutions to server static content (and the mirror bucket concept is better that server-server object sync-based solutions, IMHO)

PS: I am now considering GeoIP-based DNS in the future, for distributing origin servers globally, but there is no rush for this at the moment.

I wish one of the free DNS providers like SiteLutions offered GeoIP-based DNS services. Do you know of any?

Cheers!

--------------- Added [DATE]1252535963[/DATE] at [TIME]1252535963[/TIME] ---------------

Originally Posted by john2k

To see the real power and benefits of a CDN, we can use Highwinds for an example. They streamed coverage of the presidential inauguration to a peak of 625,000 concurrent visitors using 310Gbps bandwidth. They could have done this from a single datacenter, but the viewing would not have been optimal for some viewers due to the network issue.

RE: Highwinds

Highwinds does not appear to publish their pricing model like Amazon and SimpleCDN.

Also, since we are taking vBulletin forums, most forums serve small images (buttons, attachments, icons, avatars), CSS files and JavaScript (as static content).

Forums are not really applications that serve streaming coverage of presidential inaugurations (that is not really vBulletin). Forums, like vBulletin et al, generally have PHP/MySQL origin-server requirements and static content of small images (avatars, buttons, icons, attachments), CSS files and (clientside) JavaScript.

Bringing massive streaming content requirements into the discussion has very little to with a "normal" vBulletin application, frankly speaking, which would be 99.99+ vBulletin sites.

[RedWingFan]

Originally Posted by imported_silkroad

It is a lot of work to move vB static object to a CDN, so much is hard coded without phrasing or style vars. Some are hard coded in the dB. Some plugins are even worse. I could not get a 100% solution, but I'm happy with the 99% solution for now.

Did you go the replacement variable route, or did you do something else? I realize that I'm probably missing a handful of files, but at least I have the majority of them on the CDN. My solution may be 95%...

P.S. I'm glad it worked out for you! I, too, like the Mirror Bucket method vs. uploading, as it also takes into account what I'd call "semi static" images like avatars, where members are uploading new avatars all day long. No worries on how to sync them.

Originally Posted by john2k

In my opinion, that's what CDNs are really being created for. But, I use a CDN for basically the same reason as you. Last month I offloaded just under 50 million image views to a CDN. The sole reason that I began using a CDN wasn't about the network latency benefit but was to reduce load on my webserver until my new server is built & colocated. Even after my new server is online I might keep images running from a CDN but am not certain about that just yet.

One drawback (not really a drawback, but...) is that we have our static files out there on the CDN, served out quickly, but the rest of the site is still hosted on a single server. We really aren't exploring the full capabilities of CDN, but if it's serving our needs and doing what we need it to do, who's to argue?

Something that happened last week sort of left me amazed at how some systems administrators are not using CDNs, that could be. When the Beatles remasters were released to radio last week, using the Play MPE service, you can imagine how bogged down their servers got when everyone started their downloads. To fix the problem, they had their host sell them more bandwidth, and IIRC, they may have also had to beef up their hardware.

If this wasn't an application tailor-made to a CDN, I can't think of another! Flexible bandwidth delivery, available on demand. And I'm sure with so many edge servers, delivery itself would have been faster as well.

While they were all FLAC files, still...figure 14 or 15 CDs worth of FLACs being downloaded by hundreds of radio stations...nothing this big is going to come along in the near future, and they'll find their new configuration is overkill for what they would normally use. More expense. With CDN (or at least SimpleCDN), it's essentially "pay as you go". You pay for what you use. They could have handled the spike without needing to do anything on their end.

But what do I know? I just run a lowly music forum on someone's behalf...