I’ve been getting frustrated lately about the fact that I was getting random errors on this site.

Of course “BEWARE Sharks” doesn’t tell me a whole lot.

The problem has been going on off-and-on for a few weeks now. The blog site varies between working great around 80% of the time, partly rendering a page around 10 percent of the time (sometimes the part is just plain blank, but no error) and giving me a cute “BEWARE Sharks” error the other 10% of the time.

I know the error is coming from deep down in IIS since the location that’s being referenced isn’t on my site at all — it’s on a *.secureserver.net server which is their internal hosting domain.

I filed a support ticket and got a ticket number but I wasn’t able to find some way of updating the ticket to include a picture. It’s exactly this reason I called up their tech support.

So, as of right this second I’m on the phone with tech support to try to fix the problem… (note, I wrote this a few hours ago)

The tech told me that the server was just fine and something in the WordPress install was hosed up. So the net result of the call was a fail. I don’t much blame him though since the solution turned out to have nothing at all to do with the server that was hosting the blog.

So, it was problem solving time.

First off, let’s turn off the stupid shark thing. That tells me absolutely nothing.

In the root of the server I added a web.config with the following.

<configuration>
  <system.webServer>
    <asp scriptErrorSentToBrowser="true"/>
    <httpErrors errorMode="Detailed"/>
  </system.webServer>
</configuration>

This successfully got rid of the shark. I was able to see that the PHP FAST CGI runner was timing out.

Foo! That’s not telling me much more than I already know! I learned that the timeout was 60 seconds, but not much else.

Googling around for “WordPress 500 Error” mostly pointed to misbehaving plug-ins or themes. Thankfully I have a few other sites hosted in the same IIS instance and they have different sets of plug-ins. They were having the identical issue as.

At this point I started to turn on the debug mode of WordPress by setting debug mode in the wp-config.php file:

define('WP_DEBUG', true);

This didn’t get me a whole lot more info. Still things were varying between slow and dead. Mostly dead.

I googled around a bit more to see if anyone else had this problem and some people did have a similar problem. Several folks mentioned optimizing the MySQL database. That’s something that I’ve not done yet so it’s worth a try.

Logging onto GoDaddy I went to manage the database so I could optimize it. The problem was the DB interface as slow as well. It was very similar to how the site felt.

!

So I had a thought: “I wonder if the MySQL server is hosed?”

I backed up the database, created a new one and restored the backup to the new database. From looking at the interface these databases resided on very different servers. The old one lived at 173.201.88.* and the new one at 97.74.31.*. Well that’s a plus.

The management interface for the new database was quick!

From here it was coasting as I pointed the WordPress installs over to the new database. They were restored from the old DB so nothing at all changed. A few rapid-fire edits to the wp-config.php’s to set the DB settings to the server was all it took to get things retargeted to the working database.

And now we have the happy ending: things are fast again!