I've been trying out a service called CloudFlare on my blog and ClickTrackProfit. The goal of CF is to add a layer of security to your website.

It blocks bots, spammers, and viruses from even getting to your server. So it's like a firewall. But at the same time it caches your static content like images and javascripts. So it's like a CDN.

To my surprise it's worked very good and was incredibly easy to setup. All you do is transfer your DNS to them, and they take care of the rest. It's like magic. It's been working so great and easy that I thought it wasn't doing anything!

But it is, and it's reduced the load by about 50%. A small fraction is the bots being blocked, but the majority is the system caching content making it faster and reducing our bandwidth bill. Cool!

Without going into details, I haven't tried it with any of our traffic exchanges. We have a unique situation where at the present time CloudFlare wouldn't work with our setup, but I am working on it so we can. The benefits so far have been worth it!

Geek Alert! Geek Alert! Geek Alert! That's my way of saying Jon Olson stop reading you'll bore yourself to death but please till retweet anyways!

The past few hours I've been unlearning or relearning a tactic I've been using to make things faster. Turns out, you can make it slower by making it faster. Understand that? Neither did I.

So let's get the story started. Well, we use a super cluster for our hosting. It's a rock solid, never goes offline type cluster. Super cool right? Well a few days ago I noticed it was starting to act slow*. In fact, everyone did. Not cool.

Come to find out, I've been using APC Cache in PHP. Well I was actually over using it. It was slowly eating up RAM in our web servers, and maybe even leaking it. I know in the past bug fixes said it did it, I don't know if it was or not (I'm not that nerdy). Anyways, all this time I've been using it to the max not realizing how much RAM it was using up. And funny enough our cluster is so fast it's faster NOT using it.

So now I get to go through all the code and decide which places to remove it. Yay! It's actually not been that bad, but every single time I find it used and I have to rewrite code it's like a huuuge reminder it was my bad! Thankfully our server people are super cool and don't get upset when we get on the phone with them and have conference calls with their team only to find out it was me.

The moral of the story I guess is to keep an eye on *EVERYTHING*. Especially when you keep growing like we are, the slightest changes can have the craziest effects. We're up to 1,330 queries per second on our DB server now. Huya!

*Disclaimer: I put it at the bottom because Jon's not gonna read this far, but he did tell me it was acting slow a week or so ago but I didn't notice it so I thought it was silly Canadian internet speeds. I mean c'mon Canada, you should have 31/21 innernets too..

I just found out about an exchange that lost it's database, and the only good backup was from a few months ago. This is not good! So I thought it was a good time to remind all the owners out there to do backups! Here are some things to consider:

• Downloading your files via FTP is NOT backing up your MySQL database. Just the files.
• While many hosts will say they do backups for you, most will say they aren't responsible for keeping backups. Read the fine print.
• The backups need to be daily at a minimum.
• The backups need to be automated. If it's not automatic, it will get forgotten and statistically right before you need them.
• Once automated you should be checking that the backups are being saved regularly. Automated things stop working all the time!
• RAID is not enough.

You'll also want to be sure your backups are in multiple locations. For example, some servers have multiple drives on them. So your first thought is to have one backup drive, one live drive right? WRONG. Doing that is a good idea, but it still leaves one point of failure: the server. Ideally you should have multiple layers of protection:

1. RAID 1, 5, or 10. This uses multiple drives with redundancy. If one of them dies the data is still there. I've never had a hard drive fail on me completely before, but I have had a server drive start warning me it was going to die. If that were to happen, you can rebuild your RAID array and have your data back as it was.
2. On Site. Many server providers have storage available for backups. This is great because if you need to grab the backup, its in their network so it should be much faster to restore than uploading from outside the network.
3. Remote Location. This is a must, you want a copy of your backups outside of your host's network. So if they really get knocked out you can restore it on another host. Remember when The Planet caught on fire and half the exchanges were offline for hours? What if a fire destroyed your server and the backup server on site? I use Amazon S3 because it's reliable and cheap.
4. Your own office. Sometimes things can go wrong, and there is nothing better than having a copy locally. It also makes you feel alot better knowing you've got it right there with you.

So what do I do? Well I told you - Backup MySQL to Amazon S3 - but in addition I also have it FTP a copy to my office where I have a ReadyNAS Pro running 24/7 on a battery backup [UPS]. I can easily check the backups, open them up and make sure it's all good, and it's 100% automated. This unit itself has RAID so I'm covering my bases as much as possible. You really can't have too many backups in place!

There are all sorts of ways to backup MySQL to Amazon S3 floating around the interent, but the only problem is that many of them require all sorts of things. I wanted to have my MySQL database on my WHM/cPanel server backed up automatically to Amazon S3, in the easiest way possible. Here's what I did:

Get Amazon S3

It's dead cheap and way easy to signup. There is a button to the right of this page. Once you have it all ready to go, hover over the "Your Web Services Account" and click the "AWS Access Identifiers" link. This is where you can get the secret code and access key needed later on.

Install Net::Amazon::S3

This you may or may not have to do, but it's way easy with WHM. Just login, on the left menu find "Install a Perl Module". Then enter Net::Amazon::S3 and click search. It found 3 items for me, just click on the one that says "Net::Amazon::S3". Hard wasn't it?

Install BackupManager

Note that I'm using the Devel 0.7.9 version because it supports S3. The commands below were via SSH logged in as root.

1. # wget http://www.backup-manager.org/download/backup-manager-0.7.9.tar.gz
2. # gzip -d backup-manager-0.7.9.tar.gz
3. # tar -xvf backup-manager-0.7.9.tar
4. # cd backup-manager-0.7.9
5. # make install
6. # cp /usr/share/backup-manager/backup-manager.conf.tpl /etc/backup-manager.conf

Configure BackupManager

There is a whole bunch of configuration options available, but I'll only go through the options to *only* backup a MySQL database and *only* send it to Amazon S3. This should be enough to get you started.

1. # pico -w /etc/backup-manager.conf
2. Use CTRL + W to find the text below, and change accordingly. Bold text is what you want to change to your specific settings.

• export BM_ARCHIVE_METHOD="mysql"
• export BM_MYSQL_DATABASES="dbname1 dbname2 dbname3"
• export BM_MYSQL_ADMINLOGIN="mysqlusername"
• export BM_MYSQL_ADMINPASS="mysqlpassword"
• export BM_UPLOAD_METHOD="s3"
• export BM_UPLOAD_S3_DESTINATION="s3bucketname"
• export BM_UPLOAD_S3_ACCESS_KEY="s3accesskey"
• export BM_UPLOAD_S3_SECRET_KEY="s3secretkey"

1. Press CTRL + X to close and "Y" to save

Sneaky Secret

This will only work if you have *all* InnoDB tables. If you do, and you want backups to not stall your server, let's get your hands dirty:

1. # pico /usr/share/backup-manager/backup-methods.sh
2. CTRL+W (search for --opt)
3. Replace "--opt" with "--opt --single-transaction"
4. CTRL+X to close and "Y" to save

This will turn on snapshot backups. InnoDB is able to take a snapshot of the entire database and dump it without locking the tables. This is the difference between your server database holding up the entire server and things running as if no backup is running. Some day I'll contact the backup-manager people to have them put it in..

Run Configure BackupManager

The first time you run it, you want to do it while you are there with verbose turned on. This way if any errors happen, you'll know right away. To run it simply type:

1. # /usr/sbin/backup-manager --verbose

Setup the Cron Job

If that runs without any errors, then the next step is to setup your cron jobs. Type the following, substituting the bold 45 for the minute you want it to run, and the bold 1 for the hour you want it to run. Remove --verbose if you don't want to get emails with all the details.

1. # crontab -e
2. press o
3. type "45 1 * * * /usr/sbin/backup-manager --verbose"
4. press esc
5. type ZZ to save or :q! to quit if you make a mistake
6. # crontab -l

The last command should list all your cron jobs. If it looks good, your golden. Just don't forget that the quotes are not part of the command. You are typing what is inside the quotes.

Accessing your Files with Firefox

Well this is the kicker..  Accessing the files with S3 Firefox Organizer is way easy. It's a plugin that sits in your bottom status bar of Firefox and you can just click it anytime and see your files. You can easily use it to synchronize folders on your computer too (so you can easily download those backups anytime!).

I think it's really cool that with Media Temple (dv) you have your own defined amount of ram. This means you can fully utilize that memory to the max! The first thing I did when I got my account was installed APC Cache.

What is APC Cache? Well it is an opcode cache. The gist of it is this.. It stores your PHP scripts in the server's memory already compiled. This means the next time someone hits that page, it only has to execute. It doesn't need to load all the files up which saves on disk speed and it doesn't need to compile everything which saves on CPU usage. It can really make things fast.

1. Setup Root Access

Goto the "Root Access & Developer Tools" page inside the Media Temple AccountCenter. You'll need to login to the server with root access to edit the proper files. Make sure your password is *ultra secure*.

2. SSH Into the Server and Install APC

Download Putty if you don't have an SSH program. Once logged in type the following commands:

• cd /usr/local/src
• wget http://pecl.php.net/get/APC-3.0.19.tgz
• gunzip -c APC-3.0.19.tgz | tar xf -
• cd APC-3.0.19
• ./configure --enable-apc --enable-apc-mmap --with-apxs2=/usr/sbin/apxs --with-php-config=/usr/bin/php-config
• make
• make install

Note that each bullet is a one line command. That really long one you'll have to ensure is all on one line.

3. Edit php.ini to tell PHP to use APC

• vi +/extension_dir /etc/php.ini
• press i
• press enter to start a new line
• type extension = "apc.so"
• press esc and then type :wq to exit and save (if you mess up type :q! to quit without saving)
• service httpd stop
• service httpd start

That should do it! It's pretty simple indeed, but the effect is huge. If you are using WHM/Cpanel I recommend the instructions here.

This tip goes out to all the traffic exchange owners out there who are wondering why their massive server can't handle the load.

Apache has a feature called KeepAlive. Basically this keeps the connection alive for all the requests a computer has. IE: the page, all the images, etc.

This is great, however by default it keeps the connection open for 15 seconds (KeepAliveTimeout). With surfbars being 15 seconds and under, this is essentially keeping all the connections open for each user surfing. The end result is apache using up all it's connections.

You can increase your max connections, but that will require more memory and all the other jazz. Or you can change the time down. I set mine to 3 seconds, because the surfbar should be loaded within 3 seconds. If it takes longer, it just recreates the connection. The end result is less connections being open all the time, and the server can handle more visitors faster.

To change it, you'll need to edit your httpd.conf file

Update: I actually turn KeepAlive completely off now. It makes high traffic sites load better ;-)