Experiment conditions – A random URL fetched every 5 minutes from a pool of 27 URLs. Only the HTML is fetched, no images or other files. Web hosting using godaddy unlimited linux plan. Database with direct external access enabled. WP-Super-Cache enabled in half cache mode.

The numbers were chosen particularly to cause a lot of cache misses (27 pages with a 5 minute interval is greater than the cache expiration time). Approximately 32% of the page retrievals resulted in cache hits resulting in less than 1 second retrieval time. A total of 71% of the retrievals occurred in 2 seconds or less, and 85% in 3 seconds or less. Those are the retrievals that I’d consider acceptable. However, 7% of the requests took greater than 10 seconds. That’s getting into the range where people will think a site is down or unresponsive. 4% of them took 20 seconds or more. Two of the requests actually failed due to database timeout.

One of the options when I created this database was whether or not to enable external direct database access. I originally chose this option so that I could do easy database backups via mysql to my linux boxes at home. According to the godaddy website, databases with external access are hosted on a different server than those without. For this reason, I decided to re-import the wordpress site into a database without external direct access and see if there was a difference in performance.

Experimental conditions – same as above, but database with external direct access disabled.

This time 97% of the requests were 2 seconds or less, and 100% were 3 seconds or less. There were no page retrievals over 3 seconds. There were no timeouts.

This is good news as these are finally numbers that I’m confident will lead to a successful website using wordpress. I’m not sure whether the issue was that the databases that allow external direct access are slower than those that do not, or simply that I’ve been lucky enough that I migrated to a database server that receives less load than the others. Pinging the two servers (the original one that allowed external access and the new one that does not) reveals that they are as expected two different IP addresses, and likely two different servers.

I’ll keep monitoring the site with a long-term benchmark to see whether the new performance continues to be acceptable.

Updated — I did, for the most part, resolve this issue to my satisfaction by changing some database parameters and adding a cache mod to Wordpress. Full details, with updated benchmarks using the new configuration can be found on this page: http://www.smbaker.com/more-wordpress-benchmarks-on-godaddy-hosting

However, no sooner did I get to doing some serious site work and I experienced a <gasp!> timeout from the website. I haven’t had a timeout on one of my websites that I can remember in years. So I decided to go to the root page of the wordpress blog and hit the refresh button. Sure enough, there was a bunch of variability in the page generation time.

Being a network guy, I constructed some simple benchmarks and set them to work for about a two hour period while I was off to lunch. Let’s cut to the chase, the first histogram is below.

So what we have a bove is a histogram that shows page retrieval time on the x-axis and number of pages on the y axis. I repeatedly fetched the wordpres homepage (http://www.smbaker.com/wordpress/) of this website every 15 seconds and ran this test for about two hours.

Experimental conditions – the website is a simple wordpress CMS configuration, about a dozen pages online at the time of the benchmark. The WP-Super-Cache/WP-Cache addons are not enabled. The website is receiving no other traffic than what is being generated by the benchmark. The test was run from 11:00am to 1:00pm pacific time. Web package is the godaddy ‘unlimited plan’.

The first thing we notice is that 72% of the pages were served in 0.6 seconds or less. 84% of the pages were served in 1 second or less. Unfortunately, that’s where the good news ends. 8% of the pages took over 2.5 seconds or more to fetch. IMO, once we start getting to more than a couple seconds that’s where websites start looking sluggish. So, 8% of the people who visit this very simple wordpress site will experience a sluggish site. Let’s look into the outlying data a bit closer.

4% of the pages took more than 5 seconds. Of that, 2% of the pages actually took more than 10 seconds. 10 seconds???? A couple of page retrievals took in excess of 20 seconds. This is the year 2010, not the year 1995.

The first thing to do is to factor out non-server related factors. Things like my PC here at home, my ISP, the network connections between my ISP and godaddy, routers, dropped packets, etc. All of the stuff that makes the Internet unpredictable. I was thinking of this ahead of time and I ran a benchmark fetching a static non-wordpress page at the same time as the above benchmark. The “static” page has no PHP. It doesn’t use any database access. Here’s a histogram of its’ behavior:

Here we can see that on a non-dynamic/non-database page, all of the accesses occur in 0.2 seconds or less. That’s enough to convince me that the issue isn’t my ISP, my home computer, or any router in the pipe.

As further anecdotal evidence while trying to update this blog post, I experienced three incidents of timeouts and “page unavailable” errors when trying to commit changes to this draft. I’ve also experienced six more incidents of extremely long load times (greater than 20 seconds) while trying to open simple wordpress interface pages (the edit page, the categories page, etc). I suspect that the database performance is even worse at storing information than retrieving it.

Updated — Read the follow-up entry: http://www.smbaker.com/more-wordpress-benchmarks-on-godaddy-hosting