ERROR! MySQL server PID file could not be found!

UPDATE: cPanel put out a fix on Oct 12 2011, in the latest WHM EDGE (version 11.31.1.6). Mind you, it may not help if you’re already in this situation (so keep reading), but should help prevent it from happening to others – from the looks of it the depreciated options will be handled during the upgrade, assuming you’ve upgraded WHM to beyond 11.31.1.4  before upgrading MySQL to 5.5 anyway.

There are plenty of possible reasons, but one strong possibility is that it doesn’t like something in your old my.cnf file. Some things in 5.0 were depreciated and cause newer versions of MySQL to choke on startup (I found this out playing with 5.1 on another server, and it again hit me again recently).

The quick-fix in this case is to simply rename your existing my.cnf file (located in /etc/my.cnf ), and try restarting MySQL again ( /etc/rc.d/init.d/mysql restart should do the trick). If it works, create a new my.cnf (or copy over one of the defaults included with the installation) and start re-adding your previous tweaks, being sure to restart MySQL after each change. Eventually you’ll probably hit the one that made MySQL choke, and you can simply omit it at that point.

If you’ve been using shadowbox and trying to validate through the w3c’s validator, one of these headaches might look like this:

The message is “Bad value shadowbox for attribute rel on element a: Keyword shadowbox is not registered.”

–

What does this mean? Well, there are only certain things you’re technically allowed to put in a “rel” tag. For example, the following is okay:

<a href=”image.png” rel=”nofollow”>

“nofollow” is a valid “rel” attribute. You’ll find other valid attributes in the links provided by the W3C validator. Unfortunately, you won’t find things like lightbox, shadowbox, etc as valid rel attributes. And as you’re probably aware, the W3C’s validator can be rather picky.

—

The first thing I tried was looking for an alternative. Fancybox ended up being one of the few which appeared to use id’s and classes instead of rel, but for the life of me, I couldn’t get it working. Maybe it doesn’t recognize the new html5 doctype (it mentions it’s picky). Or maybe I just messed up trying to implement it (yeah yeah, probably this).

—

What I tried next, and what ended up working, was looking through shadowbox’s js file. I figured that “rel” must be mentioned in the file somewhere, and maybe it would be as simple as changing anything that says “rel” into “class“.

As it turned out, it was that easy.

There were 2 instances of “rel“, which I changed into “class“. After making the changes, saving the file, editing my html to change every rel=”shadowbox” into class=”shadowbox”, and re-validating through W3C, I got the following:

Success!
(the 1 warning was the W3C’s standard message about the HTML5 validator being experimental right now)

—

If you’re looking to do the same thing, it’s pretty easy. The shadowbox.js file is minified, so rather than hurting your eyes trying to find the right places to change, simply use your favorite editor to do a quick search (and replace) of “rel” to “class”. Save it, update your html, and you should be golden.

—

Of course, if you upgrade Shadowbox.js in the future, you’ll have to remember make the change to the new version.

Incidentally, whether it’s worth it to begin with is something you’ll have to decide on your own – being 100% compliant isn’t necessarily critical – I mean… I don’t forsee your site crashing browsers or even rendering wrong simply because you have rel attributes you technically shouldn’t. And heck, even Google’s main search page fails the html5 check (with 37 errors no less).

If that nice green validation bar makes you feel all warm and fuzzy though (I know it does for me!), hopefully the above instructions help you out.

Whitelisting only goes so far – the fact that I change IP addresses a lot (and am trying to remember which of the dozens of different passwords I might have used) doesn’t help.

Incidentally, WiredTree (my current VPS host) has been rather gracious (and fast) in getting me un-banned. They’re a great host in so many ways.

—

Anyway, there are a few possible ways to get back in all on your own, and I’ll mention a couple of them here.

METHOD #1 – SSH and manual unblocking in CSF and CPHULKD

Warning: Before messing with this stuff, make sure you’ve got good backups – if you don’t, it might be worth simply asking your host to unblock you from their end. While I’ve tried to be accurate here, it’s possible that I’ve made a mistake (or that the writeup will be messed up the next time I do a theme change), that you will make a mistake, or that your system is configured differently and that something will still bork your machine regardless. Proceed at your own risk!

1) SSH in as root. If it lets you, great. If not, you may be able to do so through another server you have SSH access to (since it’ll appear you’re logging in through the other server’s IP address). To do this, SSH into server2 and from there SSH into server1.

Regardless as to the route you go, once you’ve managed to SSH in, there are 2 common places where you may have been banned – csf and cphulkd.

WHITELISTING YOUR IP IN CSF

First, you’ll try to add your IP address to csf (the most common if you can’t even visit your websites on the server). It’s dead-simple. Type the following:

 csf -a xxx.xxx.xxx.xxx

(replace xxx.xxx.xxx.xxx with your current IP address)

If that’s where you were banned, you’ll see the following message:

Removing xxx.xxx.xxx.xxx from csf.deny and iptables DROP…
Adding xxx.xxx.xxx.xxx to csf.allow and iptables ACCEPT…

Now try accessing the server again. If it still doesn’t work, you’ll have to check cpuhulkd.

REMOVING YOURSELF FROM THE CPHULKD BLOCKLIST:

(note: credit for this solution comes from “thobarn” on the cpanel.net forums. Feel free to visit that page for the original, more detailed version which includes the command to back up the database).

To check cphulkd and remove yourself from the blacklist, type the following:

mysql

(prompt should change to “mysql>”)

use cphulkd;

(should say “Database changed”)
(in the next line, replace xxx.xxx.xxx.xxx with your ip address. Note that ` and ‘ are used in different places. ` is left of the 1 key on most keyboards and shares with the tilde (~). ‘ is the apostrophe you are probably accustomed to typing with.)

SELECT * FROM `brutes` WHERE `IP`=’xxx.xxx.xxx.xxx’;

(note: you should see your IP come up now. If instead it says “Empty Set”, you were NOT banned through cpuhulkd and don’t need to do the next DELETE line. If you got an ERROR message about your SQL syntax, you probably messed up your typing and will need to try again, remembering to use the correct ‘ ` and ; )

DELETE FROM `brutes` WHERE `IP`=’xxx.xxx.xxx.xxx’;

(again, replace the xxx.xx parts with your IP address. Remember, only do the DELETE line if it spit out your IP address when you did the SELECT)

quit

Hopefully, you’re unblocked now. Try logging into WHM – if it’s still not working, you’ve been blocked via some other method and may want to consider contacting your web host provider for support.

—

METHOD #2 – switching your IP address

The easiest method (doesn’t involve SSH) is to simply switch your IP address, at least temporarily. Before doing so, TAKE NOTE of your current IP address because you’ll probably want to whitelist it.

1. If you’re at home, many ISP’s don’t give you a static IP and this is one case where that might actually work to your benefit. Reset your modem and you might end up with a new IP – try to get back in.
2. Another option is to head to another location to log in. If you’re friendly with the neighbours or happen to be 5 minutes away from work, this could be an option.
3. A slightly more dangerous option is to check the nearby wireless connections to see if there’s an unsecured wireless network around (a neighbour’s for example), and connect to it. Beyond the moral (and possibly legal) implications here, if somebody’s purposely left their connection unsecured for nefarious purposes, well… let’s just say it’s an option to be avoided. If you do go this route, be sure to disconnect from that network afterwards – if nothing else, your neighbour might be paying through the nose for data-transfer or having speed issues they can’t figure out, and leeching on to their internet access just plain isn’t nice.

Once you’ve connected via another IP, log into WHM and get to the cPHulk Brute Force Protection page (Main —> Security Center —> cPHulk Brute Force Protection).

From here, you can:

• Whitelist yourself (Trusted IP List). Type in your IP address. If you’re only connected through another IP temporarily, make sure you enter the IP address you wrote down earlier!. Once you’ve typed in the IP address, click the “Quick Add” button, and you should be good to go. If there are other IP addresses you regularly connect from, you may want to add them as well. If your ISP doesn’t give you a static IP address it’s possible to enter a range, but I won’t go into the details here.
• Edit the Blacklist (lower right of the picture) – It’ll bring up a page showing blacklisted IP addresses – make sure yours isn’t on it and delete if so!
• Clear failed logins ( the “Flush DB” button). While I usually do this just to make sure I don’t have any problems, this will also flush all the naughty-people from the database who’ve been trying to break in, meaning they’ll get a few more attempts at your server if they’re still trying. Use at your own discretion.

Get back on your regular connection/IP, and hopefully you should be able to log in.

—

—

Ideally, you’ll be in and good-to-go at this point.

—

—

Feel free to leave a comment below, particularly if:

• Something above has worked for you.
• Something above hasn’t worked for you.
• You know of additional methods (perhaps better methods!) that may help others.

An unfortunate situation, but it’s nice to see that they’re trying to keep people informed and are working with some of their competition (or… at least competition a few days ago) to help customers move on. I’d imagine SimpleCDN’s business is pretty much toast – something like this would be very difficult to ever recover from.

Popped open one of my sites, and it was taking forever to load… no images. Tried another, and another.

While I use a VPS for the main site, I use HostGator shared hosting for some of my smaller sites, the downloads I provide here, as well as for downloads through my other sites (big and small). It’s hard to beat the unlimited bandwidth provided at the price they offer it. If you’re looking at starting up a website, HostGator might be worth a look (don’t forget to use the coupon code mentioned in the banner above!)

Yep, the CDN wasn’t responding. Turns out SimpleCDN is down. Upon logging trying to hit the admin section of the site, I was presented with the following:

Dear SimpleCDN Customer,
-
I am writing this letter to update you on a situation that has been developing for the past 72 hours between SimpleCDN and our technology and infrastructure providers, SoftLayer and Hosting Services, Inc.
-
Two days ago these organizations decided to immediately terminate our contract and suspend service on much of our infrastructure in Dallas, Seattle and Washington, D.C. This infrastructure constitutes the majority of our delivery network for our value services, including on-demand and live streaming services.
-
Absolutely no valid reason or warning was or has been given for this termination, and our best guess currently is that these organizations could not provide the services that we contracted and paid for, so instead they decided that terminating services would be the best solution for them.
-
We have already started to take legal action against these organizations, however thus far we have not gotten either party to reconsider their position. As it stands now, certain SimpleCDN services will begin to fail within the next few days as additional services are terminated.
-
We believe the actions of Hosting Services, Inc. and SoftLayer constitute a deliberate attempt to cripple SimpleCDN’s current service offering.
-
SoftLayer and Hosting Services / UK2 Group also resell “CDN” services at a much higher price point, and it is clear these actions constitute a conspiracy to remove us, and many other corporations affected by their reckless actions, from the marketplace.
-
I invite you to contact these organizations directly to voice your frustration and opinions on this matter, while we’ll continue to ensure access is available to key services for backing up your data currently contained on the CDN for as long as possible.
-
Hosting Services, Inc. – UK2 Group Contacts:
Jeff Hunsaker
President/COO UK2 Group / Hosting Services, Inc.
jeff.hunsaker@uk2group.com
801.368.3358
-
Ditlev Bredahl
ditlev@uk2group.com
-
SoftLayer Contacts:
Support Team at 1-866-398-7638
-
Lance Crosby, CEO
214-442-0600
-
I understand how difficult this is for you, and for the past two days we have been scrambling to make alternative arrangements, but not enough time has been given to secure additional delivery resources.
-
Our support team will be available 24/7 at support.simplecdn.com to answer any of your questions, and assist you with alternative services in any way possible.
-
You may contact me directly at: frank.wilson@simplecdn.com or via our corporate number at 800-269-3033 ext 704.
-
Sincerely,
-
Frank Wilson
Chief Engineer, SimpleCDN

Well, there goes my cheap CDN provider.

Fortunately I’ve made periodic backups and the VPS I’m on should be more than up to the task of serving everything in the interim – if you’re stuck waiting on images to load on another one of my sites, it’ll probably be an hour or two for the new DNS to resolve, so check back shortly.

Last year I had a little surprise in that Warcraft-Maps.com was listed as an attack site. Turned out that either Burst or ValueClick were running some not-so-nice ads and got the site flagged. It did eventually un-flag, but I wasn’t thrilled.

I always thought ValueClick was the problem. They’ve got a huge amount of ads running on their network, and they don’t seem as selective as Burst!. You can imagine my surprise a few minutes ago though, when Kaspersky did the little “violin” when I visited my site. Turned out Burst doesn’t behave so well after all.

-

Last month, I dumped ValueClick – I was only serving Burst! Media ads, and Google ads.

Well, time to say goodbye to Burst. It’s rather unfortunate that one of the “better” providers has gone downhill in this way.

-

The reason I originally ran CPM ads to begin with was because the bandwidth that Warcraft-Maps.com used was the big part in upgrading hosting packages over the last 3 years. It used more than all the other sites combined, and effectively cost the most to run.

If you’ve ever wondered why “download” sites bombard you with ads, popups, pop-unders, and everything else, it’s because that bandwidth isn’t free – it’s got to be paid for somehow. As much as I despise pop-unders, I’ll admit I did have them running on the Warcraft-Maps site for quite some time.

And yes, running pop-unders on one of my sites did leave me with a dirty feeling inside – I’m still recovering.

-

However, that’s all in the past now. I have to give a big thanks to HostGator actually. Their unlimited hosting has allowed me to throw all the bandwidth-intensive stuff on there at a cost of under $10/month. How unlimited is unlimited? Well, Brent from HostGator recently posted on WHT, mentioning that he regularly comes across accounts using over 5TB of bandwidth per month. I’m way under that.

In any case, Warcraft-Maps.com is now running only Adsense stuff, which has generally shown to be safe to viewers.

Goodbye Burst… and here I thought ValueClick was the problem. Turns out you both were.

After about a week of not receiving any messages through the contact form on one of them, I suddenly realized… “ya know… it’s been a while”. I tried sending myself a test message through the contact form, and never received it. Sending from another email account worked though. Strange…..

Before going any further it’s worth noting that I’m using Google Apps on the aforementioned site for mail (gmail for domains).

To narrow down the cause, I did a couple things. First, I came across a little script on the Joomla forums (thanks to “ChiefGoFor”). It basically tests the PHP mail function (which Joomla uses by default) and looks like this:

<?php
mail(“youremail@domain.com”, “Testing PHP mail”, “Email sent successfully”);
echo “script complete.”;
?>

I made a file called “testmail.php”, plunked that code in, changed the email address to a hotmail one that I own, and opened in in my web browser. It worked.

——

Next I tried changing the email address it sends to from within the Joomla site, again, pointing it to the hotmail one I tried above.

It worked!

Problem was obviously either Google not accepting messages from the server, or the server not sending to Google for some reason.

I popped open WHM, and ran the “Mail Troubleshooter” (under the “Email” section in WHM). When I typed in the address hosted through Google Apps, it spit out the following message:

virtual_aliases via virtual_aliases router forced address failure

Fun.

I tried entering a hotmail address, and it showed the proper MX lookups through Hotmail.

Now all the pieces were falling together.

——

Here’s what was happening….

• The DNS isn’t hosted on the web server in my case. It’s hosted elsewhere. It’s properly set up (MX records and all).
• The web server however doesn’t look at the DNS server for a site contained on the web server. After all, why would it spend the time to look itself up?
• In short, while MX records were properly set up on the DNS server, they also have to be set up on the web server if it ever sends mail to an email address that reflects a domain on the server which is hosted elsewhere.

I’ll draw a little picture to explain it a little better.

As you can see from my wonderful drawing, if your mail is hosted somewhere else, it won’t matter that your separately-hosted DNS server was set up correctly – you’ll still have to add the MX entries to the web server (otherwise it’ll just look at itself).

The good news is that for those who self-host their DNS, WHM/CPanel will pick up the MX entries when you add them to the zone file.

For everyone else, MX entries can be added easily in CPanel’s “MX Entry” section.

If your site is pretty basic, you probably don’t need them, and having them load every time just makes it that much more painful for your dial-up viewers. Heck, mootools.js alone is 74 kb !

So how do you get rid of mootools? It’s pretty simple code that you throw in your template’s HTML file. Hopefully, you know where the template is, but if not, you can find it one of two ways (you may want to back up first just in case!):

• Browse to (and edit) the /templates/your-template-name/index.php file (located in the directory your website is in); or,
• From within Joomla’s administrator panel, choose Extensions / Template Manager , then click on your template (probably the one with a star beside it), then choose “Edit HTML“.

Depending on how the permissions are set up on your server, one method may be easier than the other. Here’s the code you’re going to put in the template:

<?php
//remove mootools.js and caption.js
$headerstuff=$this->getHeadData();
reset($headerstuff['scripts']);
foreach($headerstuff['scripts'] as $key=>$value){
unset($headerstuff['scripts'][$key]);
}
$this->setHeadData($headerstuff);
?>

Note that this goes near the top, right AFTER this:

<?php
// Prevent direct access sans Joomla!:
defined( ‘_JEXEC’ ) or die( ‘Restricted access’ );
?>

So once you’re done, the first few lines are probably going to look something like this (the blue is the stuff you’re adding):

<?php
// Prevent direct access sans Joomla!:
defined( ‘_JEXEC’ ) or die( ‘Restricted access’ );
?>

<?php
//remove mootools.js and caption.js
$headerstuff=$this->getHeadData();
reset($headerstuff['scripts']);
foreach($headerstuff['scripts'] as $key=>$value){
unset($headerstuff['scripts'][$key]);
}
$this->setHeadData($headerstuff);
?>

<!DOCTYPE html PUBL……..

That’s it! Save, load up your website, make sure to hit refresh once (F5), and view the source – no more mootools or caption.js! Your website should load faster, and dial-up users can save their tears for another site.

——

A couple final things to note:

1. Some Joomla templates (usually just the really fancy ones) may need mootools.js to operate properly. Make sure to check your template’s functionality afterwards.
2. There are a few Joomla plugins/modules/components that require mootools as well. Many lightbox modules do for example, and you may find that many image/photo/video galleries do as well.

If you have any issues, just remove that bit of code from your template and you should be good to go again.

——

Finally, as much as I’d like to take credit for the above, credit goes to someone on the Joomla forums who posted it long ago (I don’t recall who it was, or who came up with it in the first place).

It’s a bit of PHP code that can be used to get an idea as to how fast the processor is on the machine your websites are hosted on – or at least the speed you have available to you. A thanks to “webpan” of the WHT forums for putting up the code he used for his LiquidWeb test.

Basically, you create a php file that looks like this:

<?php
$startTime = microtime(true);
for ($i=0;$i<500;$i++) {
$j++;
for ($k=0;$k<10000;$k++) {
$j++;}
}
$endTime = microtime(true);
$delta = $endTime – $startTime;

echo “total time: $delta seconds.\n”;

//phpinfo();
?>

Call it “test.php” or something, and put it somewhere on your webserver – then browse and run it. You could modify it to do some more stressful math, but don’t go crazy.

I tried it on 3 hosts, and here were my results:

time in seconds - lower is better

Each test was run at 3 different time periods during the day. To make things a little more readable the times for each run are only shown to 2 decimal points. The variance here is the sum of the deviations from the average of all 3 tests.

You’ll notice the following:

• WiredTree came out on top, and VPSLink wasn’t far behind. HostGator was the slowest.
• Each run was *very* similar. There was almost no variance, indicating that none of the host machines seem to suffer from high CPU loads at certain points of the day.

—

But what does it all mean, Basil? (obligatory Austin Powers quote)

Well, as far as processor-intensive PHP tasks go, the WiredTree and VPSLink VPS’s are likely to be quicker, and pump out the results faster. In all likelihood they’re simply using faster processors than HostGator. There could very well be other reasons that HostGator came behind, but the fact of the matter is that there’s more processor speed/power available to both VPS scripts.

—

Does this mean that HostGator’s slow/bad?

Not at all.

There are so many factors that come into play, that you can’t base a host decision on one type of test. HostGator’s got a lot of servers, and I can guarantee you they’re not all the same. The same probably holds true of the VPS providers. If someone gets a brand-spanking-new machine, it’ll be faster than the old machines. It’s a “luck of the draw” thing as far as which machine you’re put on.

You also have to consider that there are many other things that come into play when you’re looking at how long it takes for a page to load somewhere. There are many things that go into tuning a server. A server that’s strapped for RAM, a poorly tuned MySQL database, a server that’s always waiting on IO, a server connected to the network with a 10Mbps port that’s being maxed out, the server location, and the datacenter’s connectivity are just a few examples of things that can really affect how long it takes for a page to load on the viewer’s end.

—

The test subjects (aka “You Rigged the Test!”)

I’ll be the first to admit that these weren’t necessarily level playing fields. Here were the candidates:

HostGator
Shared hosting plan
Apache/FCGI/SuExec

VPSLink
Link-4 VPS – Xen
Apache/SuPHP/SuExec

WiredTree
1024 VPS – Virtuozzo
LiteSpeed/LSAPI/SuExec

The way it typically works for PHP speed is this:
DSO > FastCGI >SuPHP
Litespeed’s PHP server’s a little tough to put in there although most of the info out there seems to indicate it may be faster than all the above. I have no way of knowing whether the speed of the above test is affected much by the engine serving up the PHP, although I’d expect the effect to be marginal in a test like this.

Update: SimpleCDN has changed somewhat in their offerings (there seems to be a move away from the “small customer” base), and thus, much of the following is outdated.

I recently started up an account at SimpleCDN to help offload a webserver a little bit by putting static images there.  After a couple days, I decided to give Amazon’s CloudFront a try as well.

I’ll start off by saying this was originally going to be primarily about the performance differences. However, after a few hours of testing, I found there’s not enough of a difference to be worth mentioning – neither was consistently better than the other. Performance-wise, for the most part it really boiled down to how close each test location was to the nearest respective edge server. This was relatively small-scale testing with a site that pulled about 12 images per page (and thus pulled 12 items from each CDN), but I concluded that neither’s going to make a lick of difference performance-wise… at least, not for the typical individual who’s looking at these two for solutions.

That said, time to take a look at the merits of each at a basic level:

Preface:
SimpleCDN was designed straight-up as a CDN, and meant to be simple (hence the name). CloudFront on the other hand is built upon the structure of the other Amazon services, and can be thought of as more of a “bolt-on”. In fact, CloudFront uses (and requires) the Amazon S3 service for hosting the files – CloudFront then pulls the files to the CDN from S3. These are very different approaches. SimpleCDN is generally simpler to use, and more powerful in the options it offers. That said, anyone already using Amazon S3 extensively will probably feel more at home with CloudFront.

Upload Buckets:
For those unfamiliar with the way these work, you basically upload the files you want on the CDN into what’s called a “bucket”. It’s a pretty simple concept – you basically end up with a new URL where those files are located – no different from linking to files on a separate server/website, except that these are now on a CDN and should be served closer to whichever users are requesting them. Both SimpleCDN and CloudFront can use them. For SimpleCDN you use your favorite FTP client to upload the files. For Amazon CloudFront, you put the files up on Amazon S3, and set it up to pull from there.

Mirror Buckets:
For those unfamiliar with these (also called “origin pull”), these are often easier to implement with dynamic websites – particularly those where static content you may want on the CDN (such as images) are often uploaded/added to the site. Both WordPress and Drupal have plugins for these. All the content you want on the CDN stays on your server/website. Requests for those files are redirected to the CDN which “pulls” the file(s) from the server/website, and begins serving them through the CDN. SimpleCDN has support for this. CloudFront does not.

CNAME Support:
This is often more of a “vanity” feature than anything else. It allows you to use something like cache.mywebsite.com, images.mywebsite.com, static.mywebsite.com, cdn.mywebsite.com ….. you get the idea. You basically use a subdomain or domain that you own, and use a CNAME in your DNS settings to point it to the CDN. That way, viewers see your pretty, professional-looking name as the page loads instead of an ugly long url. To be frank, most viewers won’t see/notice the difference with content that’s loaded within the page (template images, css, etc). In any case, both SimpleCDN and CloudFront offer this. SimpleCDN charges a 1-time fee of $5 for each CNAME you set up, while Amazon includes them for free (but with a max of 10 per distribution). This is one area where Amazon really has the upper hand price-wise, particularly if you’re looking to add a lot of CNAMES.

Peering/Edge Locations:
Both have a comparable number of locations, and for the most part they’re in relatively similar geographical regions. Unless you have a *very* specific geographical target (a specific city for example), neither’s likely to come ahead in this respect (the similarities were reflected in performance testing I did).

Expires Header and gzip Encoding:
SimpleCDN wins in this area hands-down. There are currently 17 combinations, and what they enable (a certain expires length, gzip, or both for example) depends on what URL you use to access the bucket making it easy to mix/match between them. As far as Amazon’s side goes, from what I understand you can set expires headers through S3 which will be pulled to CloudFront, but you need particular software to do it. CloudFront won’t gzip content either. You can technically get around it by pre-gzipping the content and using the PHP on your site to determine whether to grab the gzip or non-gzip version of items depending on the browser’s capabilities, but really… you get the idea. It’s ugly. SimpleCDN is simple, easy, and just plain comes out ahead here.

Payment:
SimpleCDN is completely pay-as-you-go, and they currently start you off with a free $15. At under 4 cents per GB, you’re looking at close to 375GB of transfer before you use it all up (minus any storage). You can also use part of this free $15 for the $5 CNAMES if you’d like. Once you’ve used it up, you’ll have to add more if you want the CDN to remain accessible. The lowest amount you can add at a time is $50. Amazon on the other hand simply bills you each month for your usage. Which is better is a matter of perspective.

Minimum Monthly Fee/Cost:
Neither have monthly fees, minimums, or costs. You pay for what you use – that’s it.

Starting price per GB of transfer:
SimpleCDN charges 3.9 cents per GB, no matter where the traffic is coming from. This gets even cheaper if you hit the 100TB mark in any given month. CloudFront on the other hand is a fair bit more expensive. Amazon charges anywhere from 17-22 cents per GB (depending on the location the content’s pulled from) for the first 10TB, after which the price starts going down. SimpleCDN is clearly ahead here.

Storage cost per GB / month:
SimpleCDN charges 75 cents per GB of storage per month. Since the Amazon content is stored on their S3 service, it’s much cheaper – starting at 15 cents per GB per month. However, with Amazon you’re also hit with all the S3 rules – so you’re charged for both data-transfer (including each time CloudFront pulls the files from S3), as well as GET/PUT/COPY/etc requests. Amazon is still likely to come out ahead here (especially if you store many terrabytes of seldom-accessed content), but it’s worth doing the math to see.

Starting cost per 10,000 GET requests:
SimpleCDN doesn’t charge for these. Amazon does, and Cloudfront will charge a penny for every 10,000 GET requests. Calculate how many static contents are on your website page that you’d be serving from the CDN. Multiply it by the page views in a month and you’ll get a rough idea as to how much this will cost.

——

A few notes I couldn’t quite squeeze up there:

• If you use SimpleCDN and decide to use CNAME’s as well, be sure to type it in correctly when creating it! Most of SimpleCDN’s website is very easy/intuitive, but the CNAME part is one area that isn’t as clear until you *read* it.
• While you can use as many expires/gzip options and combinations as you want, note that each CNAME can only point to ONE of these combinations at a time.
• There’s a Firefox plugin called S3Fox which is one of the quickest/easiest ways to upload files to Amazon’s S3 (and then push to CloudFront). You do have to read the instructions though – otherwise you’ll be right-clicking for a while to figure things out.
• Setting expires headers can help to reduce your transfer costs – possibly by a substantial amount.
• SimpleCDN has changed their policies in the past – they used to charge a flat rate depending on the file-size, and then give unlimited transfer. Hopefully they’re out of the “growing/learning/testing” phase and are well-settled on the current policies and prices but be aware that it wasn’t that long ago that things changed – they could always change again (in other words, don’t go adding enough money to cover you for the next 5 years of traffic – things could change)

So which CDN comes out ahead? Definitely SimpleCDN. It’s easier to use, it’s more flexible/powerful, it’s less than 1/4 of the cost of CloudFront, you won’t go mad with a calculator trying to predict your costs, and the “Simple” part of the name is well-earned.

That said, Amazon CloudFront is still a viable option in certain cases. If you’re already familiar with (and like) the S3 service, adding CloudFront to your mix may be a no-brainer. It’s also likely to be a less-risky bet since SimpleCDN has already scrapped/revamped their entire pricing structure once (much to the dismay of many), whereas Amazon’s been a relatively stable company for years. Amazon also has many strengths as a storage option. Finally, if you’re looking for a lot of CNAME’s and aren’t as concerned about expires headers and gzip (or are willing to go to the lengths to manually work them out), Amazon does give them out for free.

I used to use non-SEF url’s on a Joomla site, and recently turned on Joomla’s built-in SEF. Problem is that the old URL’s still “work”. Of course, this is great for people who visit – not so great when GoogleBot comes along.

GoogleBot comes happily along and for any given article sees the original archaic url with a bunch of parameters that have been there forever. Of course, there’s little incentive for it to use the “cleaner” versions. As far as it’s concerned, the archaic stuff is the original, and the new url’s are duplicate content. It could eventually change it’s mind as to the “preferred” page on it’s own, but there are a few fighting factors here. On one hand, the sitemap points to the “new” one, and it’s predominantly linked to through the current site. On the other hand, anyone who’s linked to the site in the past has linked to the “old” one, and let’s face it – it was there first.

To make the change and get Google looking at the right page, we’ll go over the things I tried that didn’t work, and then the thing I tried that did work:

Stuff that didn’t work:

• .htaccess redirects – I came mighty close with some mod_rewrite rules, but to be honest even if I had eventually got the proper ruleset set-up, copying/pasting the cryptic stuff for every article would have been very time consuming. Of course the plus side had it worked is that the “old” url’s wouldn’t even be accessible anymore, so there wouldn’t be any risk of someone linking to the depreciated url in the future. Really though, the amount of time required to create a custom rewrite rule for each URL is uncanny.
• Circumventing the existing META tags for each article – I assumed this is a loophole that would have been closed for security reasons, but I gave it a try anyway. The thought being that if you edit one of the existing META’s for an article, you can inject whatever you want into the HEAD section by closing the tag, and then inserting a new one (without closing it). As I suspected, one of the dev’s obviously thought of this, and any quotes you enter are stripped when you save the article.
• Common SEF plugins – The largest “canonical” plugin I found seemed to be more for redirecting a www to a non-www. I didn’t try it myself, but it really looked like it was designed for large-scale site-wide changes.
• Template modification – If you look back at a couple articles I wrote back in Feb (2009), you can use PHP to stuff some head tags whereever you want them. Unfortunately this would be even messier to do than setting up .htaccess stuff and would make for a very large PHP file. It also doesn’t make sense to spend the time stuffing canonical into the head section this way when spending the time on .htaccess would give *redirects* which are *better* in this case. A bad solution for many reasons, so I didn’t even bother.

What did work:

• There is small, relatively unknown plugin for Joomla called “JosTag”. Turns out it’s all that I needed.

You can find it in the Joomla Extensions Directory, or right from the developer’s site. The site is mainly french, but there’s enough english to get you by – the instructions after you install it are dead-easy.

Install it, enable the plugin, and then it’s simply a matter of throwing {tag}whatever-you-want-in-the-head{/tag} in each of your content pages. So for a canonical entry, something like this:

{tag}<link rel=”canonical” href=”http://www.website.com/current-friendly-url.html”/>{/tag}

You can stick it anywhere in the content. The downside is that you obviously have to do this for each content page, meaning you’ll have to know the “desired” url. On the plus side, it’s easy to do (especially compared to the above options), it gives you full control for each page, you can stick other stuff in the “head” section if you want it later, and it’s free.