** Update: I have released my first set of updates to the StatPress plugin. Check out the post for code to improve your blogs performance of StatPress

The WordPress plugin StatPress is an absolutely horrid plugin to use. Yes, I said it…horrid! After seeing many people praising this plugin on their sites, this is a bold statement.

As anyone who google’s my name, you’ll see that I’m a MySQL DBA for GoDaddy.com. My primary responsibilities include managing our shared hosting MySQL servers. In my job I see people using StatPress on their WordPress blogs and it kills the performance of the server, and their site. Not only does it store massive amounts of data (if you don’t change the settings), but the database design is just downright horrible. A second version of this plugin, called StatPress Reloaded, does not resolve any of the design flaws prevalent in the original StatPress plugin. Tables and columns that are regularly queried are missing integral indexes that can improve performance. Additionally, all data fields are by default TEXT (TEXT or TINYTEXT in SP Reloaded) data type, which is BAD! This plugin should be avoided at all costs.

By changing a few data types and adding a couple indexes, I’ve taken queries from this plugin from examining 140k plus rows, down to examining less than 1800 rows, a 78% decrease in rows examined. Instead, I recommend “Google Analytics for WordPress” or “Wordpress.com Stats” (the latter requires an API key from wordpress.com, the former is obviously used in conjunction with Google Analytics, which is a great stat tracking software).

I’ll agree that the features of the plugin are nice, including the real-time monitoring, the GUI, and the sheer amount of data collected. However, the design flaws mentioned previously can spell disaster for your website, especially if it is a popular site. The information provided by the StatPress plugin is useful. However, when you scratch just below the surface of this plugin, beyond the stats, the plugin itself is horrible.

I installed this plugin today to start tinkering with it to know it better so I could improve it. After only 9 hours of collecting data, I have 270 rows of data on a blog that receives only minor traffic. That’s approximately 720 rows of data per day and 21600 rows of data per month, and nearly 130,000 rows of data in 6 months. Anyone who knows anything about database design, querying a table with 130,000 rows of data and no index can spell disaster for your blog. And that’s only on a minor traffic blog. If your site gets more traffic than that, you’re in serious trouble.

I am currently working on fixing all the faults in the database design and query execution of this plugin and will post here once I have, as well as on WordPress.org. If you have further questions or comments about this plugin, please post them here and I will do my best to answer.

You may wonder why I didn’t link to the WordPress.org plugins page or the developer’s home pages for these plugins, but it’s because I don’t want to send traffic to them as, since i mentioned, they are not useful plugins. You can find them and install them on your own if you want, but as you can tell, I wouldn’t recommend it.

Check out these Related Posts