Advertisements

Beware of poorly-written CMS plugins.

CMS systems like WordPress, Drupal, Joomla, etc are rife with plug-ins and modules you can add for extra functionality, but it’s really hard to tell the load that some of those add-ons place on your system and database. When you want to have a website that won’t collapse under load (or take the server down with it) it’s important to have well-written plug-ins. Many times we install things assuming without knowing the impact they can have. Especially in the case of shared hosting where everyone shares a server, it’s important to play nice — or face the possibility of having your hosting account suspended because you put too heavy of a load on the system.

I got to experience both sides of this first hand. Some time back I had my Drupal site hosted on my own machine. In searching for a decent chat room, I found the Drupal chat room module. It was easy to install and set up, and I had a few friends joining in to give me feedback on it. After 3 or 4 people joined, it started to get really laggy. I took a look at the server and saw that it was literally drilling a hole in the SQL server. The amount of queries and load that it was producing was just unbelievable. So I disabled it. Lesson learned.

Last night while I was making some changes here, I noticed a lot of issues with pages taking forever to load, lost connections to the MySQL server, etc. Since I’m on shared hosting, the first thing I thought of was “maybe the server is having an issue?”

So I checked server status: Nothing.

I let it go and kept making edits to my pages, but noticed the problem was getting worse instead of better. I checked server status again; nothing. I thought: There has to be a problem somewhere. So I looked through my cPanel and found an icon that I thought might give me a clue: CPU Throttling.

What you see below on the left side of the red line is what I saw (I took the screenshot 15 hours after I started working the issue so I would have a clear before-and-after).

BlueHost uses a unique CPU throttling approach, not primarily to control CPU/RAM usage, but to control scripts which pound on the SQL database and make time-consuming queries. If the database gets pounded too hard, it becomes a major issue for everyone on the server. So they throttle access to the database for load spikes, and that keeps everyone happy. They say that a throttle of 500 sec/hour is acceptable, and you shouldn’t see any slowdown from it. Obviously my problem was way beyond that.

I was obviously having an issue with some script, and it needed to be fixed immediately. Since they make log files available to you for “Slow SQL queries”, I took a read through them. I saw here and there 1.3, 1.5, 1.8 seconds… not terrible. Then I saw the issues. I had SQL queries that were running 3, 4, 5, 6, even up to 8 seconds each. You know what? It wasn’t even this site. It was the feeds module I had added to another site.

So I weighed the benefit I was seeing to the site (which was zero) and went ahead and started purging the data and disabled the modules. This took a few hours (because of the already throttled connection state), and when I was done I let it idle for an hour and made sure I was no worse off than before I had started. It was nearly 3am, so off to bed I went.

I woke up this morning and immediately checked the CPU throttling chart. Not only was I under the 500sec/hr target, I was less than half of it.

screenshot-1

The worse part of this is that I was almost never aware of the issue. It wasn’t until I stated making bulk edits that I noticed there was a problem.

This does happen to be a system that only BlueHost offers. My only request might be that I could have gotten alerted via email when the load spike shot up so I could have been aware of the issue rather than having to find it out myself. But in any case, I saw it, I took care of it, and all is well.

Have an experience with a script that negatively impacted your CMS or server platform? Please share it below…

Advertisements

, , , ,

  1. #1 by Nimmy on June 27, 2010 - 7:07 pm

    Wow. Good thing you knew what you were doing. I think I would have just called Tech Support.
    My recent post BBC News – Apple issues advice to avoid iPhone flaw

    • #2 by Mike Beach on June 27, 2010 - 7:38 pm

      Thanks.

      One of the nice features they offer with this is creating a folder inside your tmp directory of all the "Slow SQL queries" which they point you to. That shows what database was involved and the structure of the SQL query and how long it ran for. A big help when troubleshooting an issue like this. I couldn't have done it without these tools. Sad but true, on another hosting provider an issue like this might have cost me my account.