Tuesday, February 10, 2009

My Love-Hate Relationship with WordPress

I love WordPress, but I hate it too!

I love WordPress because it is easy to use, install, and configure. I also love WordPress because it is updated 2-3 times a year so I don't worry about it not working with the next version of php or mysql.

I hate it because it is getting fat. This last few weeks I've been busy optimizing my own PHP scripts for better perfomance because i noticed some pages loading slowly. I've even redistributed my mysql tables and optimized mysql database table indexes. I also turned off and deleted many WordPress plugins thinking that work help. Yes,  they all did help. Unfortunately they didn't help enough. WordPress too often ends up in my "slow queries" log generated by my shared hosting.

After several months of integration of my php shop scripts with WordPress, I cut the cord!  I commented out the include file that loads the Wordpress backend so I could use the Supercache page caching plugin.

I saved around 10-18 queries!  I don't know why WordPress needs to do around 10-18 queries (depends on the version) just to let me load a plugin on an external page, but that is what Supercache was showing and I finally decided that it wasn't worth it.

Why did it take me so long to do it?  I had to set up my own page caching first.  Fortunately there are several php output or page caching script samples online. I tried one and after finding all of the bugs in the script that kept it from working I fixed it up and have it installed and working.

How much faster are external pages loading?  Comparing the processing time between the supercached versions of my external pages and the time with my own caching script. Some pages are loading between one third and one sixth of the time it took before while others are loading in about the same amount of time.  Page processing time is a good metric, but it isn't precise because it varies according to current server load. If the server is under more load, a script will take a little longer so you have to compare averages.

Another motivating factor in my decision to cut the cord to WordPress on my external pages are the somewhat recent changes to Supercache.  I'm sure Donncha has very valid reasons for doing so, but he removed the notice in HTML comments that a cached page was being served, so I couldn't easily tell if the cache was working or not ( often times it didn't appear to be serving the cache even though the files were being created).

Not really being able to tell if the cache was working or not was the straw that broke the camel's back for me. I don't like working on blind faith when it comes to my web hosting and server stability.

Don't you love it when fixing one problem helps solve another? By setting up my own separate cache, I was able to disconnect the WordPress backend and speed up pages. It made me want to do a dance of joy.

What's next in caching?  I am thinking about setting up a menu cache for dynamically created menus on the shop category and shop discount pages.  If you notice an additional speed up in the next few days on those pages, now you'll know why.

Do you cache your php output or menus?  If you haven't already set up caching today!

Friday, February 6, 2009

Heavy Serverload? Add a bad bot trap before you upgrade.

Reduce server load by blocking bad bots (and help stop spammers and sploggers)


If you're like me you are probably on a shared hosted server because
  1. You don't have a static IP or extra computer from having your sites server from home
  2. You can't afford a dedicated server.

I've noticed on my second hosting account, HostGator, that I was using many files, but many more than I really have in my website folders on my computer  and I realized that those extra files were mostly from my website cache. The cache files are created when a dynamic page loads so the next time it is called the cache is used instead of calling the database for everything.

What is a Bad Bot?


I had read in several forums that it is a good idea to block "bad bots" bad bots are internet spiders that read and copy your content for Splogs (Spam Blogs) or to steal e-mail addresses to spam. Obviously neither are good, so  I ...
  1. Added my robots.txt
  2. A few days later added my trap which points to a path blocked in my robots.txt

How does a Bad Bot Trap work?


You add  some code to your pages to a page that is blocked in robots.txt but you hide the link from human visitors. When a "bad bot" visits your website it will ignore your robots.txt instructions and follow the link. When it lands on your forbidden page, your script registers its IP address in your .htaccess file to deny access to your website.

Does a Bad Bot Trap block all Splog and Spam Bots?


While a bad bot trap does not block all spammers and sploggers using bots, it does get rid of many. Spammers and sploggers aren't very ethical so most never bother  to update their bots to check your robots.txt file to see what is allowed or not.

Because I had added some code to e-mail me whenever a bad bot was blocked, I got regular notices.  I found many sites sending me an e-mail per day about a bad bot being blocked!

About a week after adding my bot trap, I needed to go to my Hostgator control panel to open Phpmyadmin to make some changes to a database  and I noticed the sidebar showing a huge drop in files.

Although I have been trying to eliminate unnecessary files and I have combined a few include files into one with functions, It wouldn't explain the huge drop I saw.

I don't have exact numbers, but my files according to Hostgator went down by about one third. The only explaination I can think of is that blocking bad bots kept many pages from being loaded into cache.  That saves plenty of space and significantly reduces server load without hurting real visitors or reducing features.

Before you upgrade your hosting account, add a bot trap, perhaps it will be enough.