Content Management Systems are growing in popularity as a framework for running Websites. A Content Management System (CMS) automates many of the repetitive tasks associated with running a Website. Using a script framework and a database, a CMS lets organizations sponsoring Websites focus on publishing content to the Web. A CMS framework also comes bundled with all kinds of capabilities such as interactivity (discussion forums, comments, blogging), membership, syndication (RSS feeds), podcasting, and a whole lot more.

Their versatility accounts for why so many Christian ministries use CMS systems. These include:

• Orthodox Christian Network (Joomla)
• Orthodox Biz (Joomla)
• Ancient Faith Radio (Expression Engine)
• Orthodoxy Today (Wordpress)
• American Orthodox Institute (Wordpress)

But despite their growing popularity, a CMS architecture presents some unique challenges. One of the biggest is the nature of shared hosting. Most organizations or businesses aren't able to have a dedicated server. Most will have to buy inexpensive shared hosting. Shared hosting is cheap, often costing under $10.00 a month, but comes with some pretty stringent requirements. One of the most troublesome is the limit on Central Processing Unit (CPU) usage.

One of CorFun's wholly-owned sites, Orthodox Biz, recently ran up against this with our Joomla install and our hosting company - Lunarpages. In this blog, what we would like to do is pass along our experience to help others who might run into similar problems using a CMS architecture.

The problem began when Lunarpages (with whom we have a great relationship) sent us an email that our CPU usage was too high and that our site was being moved to a quarantine server.  A spike in CPU usage could indicate that a site has been hacked. A hacked site on a shared server could threaten dozens and dozens of other customer sites. Even if the site were not hacked, a site using up too many resources of the CPU could cause the server to bog down and run slowly.

Hosts used to just shut accounts down when CPU usage spiked. But they normally don't do that anymore. Now, they basically move your account to a penalty-box where you have a chance to try and fix the problem. While on the quarantine server, your site is up and you are in-business, but don't expect good response time. The site will be slow. It'll be up, but it will be slow. So, getting a site back onto a regular server is definitely a priority.

Once we found out that Orthodox Biz had been moved over, we took the following steps:

1)     We made sure the site hadn't been hacked. We checked out the files and the database. After extensive investigation, we concluded that the only things we had on file were put there by us.

2)     We analyzed all components, mambots, and modules and uninstalled everything we didn't need. Orthodox Biz is a subsidiary of CorFun. We're Web designers, which means we experiment. A lot. Okay - too much. We had a lot of mambots, especially, which we had tried out on Orthodox Biz and then decided not to use. Anything not needed was immediately uninstalled.

3)     We cleaned the database. A lot of components leave behind their database tables after they are uninstalled. This is because many components upgrade by uninstalling an old version, and installing a new one. The stray database tables simply create clutter in the database. We used phpMyAdmin from our cPanel to drop all the tables we didn't need anymore.

4)     We then optimized the database. We selected all the remaining tables, and then clicked the ‘Optimize' option. Reading a database can suck up a lot of processing power, so keeping your DB optimized can really help performance.

After doing all this, we were able to greatly shrink the amount of CPU being used. However, it was still not enough. That is when we looked at our stats on the server under AW Stats and noticed that we had sustained a huge, huge increase in hits over the past few days. This looked suspiciously like we might be sustaining attacks, so we decided to up our security.

On our Joomla installs, we us a component called sh404SEF to improve search engine optimization. This component performs what is called URL rewrite. It takes the URLs generated by Joomla, which are strings of unreadable numbers and characters, and turns them into human (and Google!) friendly strings. Instead of seeing this:

http://www.orthodoxbiz.com/index.php?option=com_contentItemid=171&id=24〈=en&task=view

You see this:

http://www.orthodoxbiz.com/directory/

This is extremely useful, of course, but sh404SEF has an additional capability. It integrates with Project Honeypot to help protect a Website from potential hackers and spammers. Project Honeypot uses distributed gathering points to compile lists of suspicious IP addresses that are most likely being used for malicious activities. (To find out more about Project Honeypot, click here.)

We registered for Project Honeypot for Orthodox Biz and got a site key. We then activated the security features for sh404SEF, and entered the key. What happened next was pure magic. Users trying to access Orthodox Biz from suspicious IP addresses were automatically blocked. They were shown a page which had a link they could click to continue to the site. Bots wouldn't be able to understand the instructions or click that link. Only humans could, which meant that malicious scripts were kept away from the site.

In the first 24 hours after activation, over 1200 access requests had been blocked by Project Honeypot. Some of those might have been innocent visitors who had the misfortune to be on the same IP address as a hacker. But, the vast majority of them were probably hackers who had been spiking up our CPU usage by running malicious scripts trying to hack into Orthodox Biz!

We also activated some other security features embedded in the sh404SEF component, but it was Project Honeypot which really made the difference.

Lunarpages confirmed that our CPU usages was back in-line with requirements, and moved us back to a production server. With all the streamlining we had done to the site, performance was positively screaming.

With that, the crisis was over.

Which step that we took made the most difference? They all contributed. Even before we activated Project Honeypot, our CPU usages was half what it had been. Our recommendation - if you are having a problem then take all of these steps as they are all good ideas. In fact, they are good things to do, even if you aren't having any specific issues.

While sh404SEF may be a Joomla-specific component, Project Honeypot can work with any system. There is probably a component for your specific flavor of CMS, or you can embed it directly yourself.

If you get a CPU notice, don't ignore it. There is a reason that you are over your limit, and it is possible to work through it.

 Glen Chancy is CIO for corfun.com and publisher of Orthodox Biz. You can contact him here .