# Query_time: 9 Lock_time: 0 Rows_sent: 0 Rows_examined: 4281017
Now if you’re not a webmaster, server administrator, or developer the above line may not mean too much to you. I understand that many people who install WordPress and dozens or more plugins really have no idea what it takes for that to all “work”. In this particular case the above line is one single query made by the “Yet Another Related Post Plugin” on a WordPress database. The query took 9 seconds and examined over 4.2 MILLION rows of data – and this was done on a shared web hosting server.
Generally a table with several thousand rows is considered to be fairly large and more often than not those identified as abusing the MySQL server are doing queries in the 100,000 to 250,000 row range. When investigating slower than normal query performance and higher than normal CPU consumption from the MySQL server I came across several copies of this query for one database, on one blog, by one customer.
In a shared environment where you’re sharing everything with others on the server including, but not limited to, the MySQL server this is simply not something that is going to be acceptable. Any provider that wishes to provide a quality performance platform to their clients will pick up on this sort of usage and will advise the client to either drop the plugin or to upgrade to another level of service where the extreme over-usage of MySQL is less likely to cause issues to others such as on a VPS platform or where it’s guaranteed not to cause issues to others such as a dedicated server.
At the end of the day, there are ultimately going to be limits as to what you can or cannot do in a shared environment no matter how amazing the provider is. My advice is to avoid the “YARPP” plugin, at least in a standard shared environment. I didn’t look to see what version of the plugin is being used so it’s possible there’s a newer version available that has a less dramatic impact on MySQL performance.
It is worth noting that the YARPP plugin has some configuration options which make it a lot less intensive to execute. The default behavior of the plugin includes some fairly aggressive analysis to determine the keyword relation of this post to other posts. This, as you point out, can be quite resource intensive.
You can tune this way down in configuration, however.
I’ve found that with many clients they are satisfied with just showing posts that share a common category or tag which results in a much lighter load as a result of using a SELECT WHERE as oppose to a full text scan.
Good to know Frank, thank you 🙂
As a web hosting professional myself, I agree that this is by far one of the worst plugins for WordPress.
I’ve seen customers single handedly raise the load of a machine by 10 with the installation of just this plugin – the author of it has never apparently used it in a live environment.
Being fairly new to WordPress, and reading about these types of issues, I’d love to see some sort of performance ratings of all the WP plugins, so that you can take that into account when deciding what plugin to use.
@Alex – That would be awesome, but I myself don’t have the time to do that sort of thing in a controlled way unfortunately.
Hi Mike,
YARPP is actually okay if used properly.
Here are the circumstances which make YARPP a troublemaker:
1. A huge site (legitimate or splog) with a lot of data to crawl.
2. Settings dialed up to check through full content.
3. No caching.
On the contrary if you:
1. Use indexes on your database.
2. Dial the setting down a bit.
3. Use caching (WP Super Cache for reliability).
You can bring YARPP CPU usage to fully manageable levels.