Yet Another Related Posts Plugin (YARPP) and Site Slowness

yarppI’ve used the excellent Yet Another Related Posts Plugin (YARPP) for about a year-and-a-half now on various client websites. Overall, I’ve found that it works great and has a responsive author who cares about updating and performance issues.

Why this post then?

Because after experiencing deadly slow post updating and post saving on a client site over the span of more than 60 days, we were finally able to track down that YARPP was causing saving or updating posts and pages to take more than a minute (sometimes up to 5 minutes or just timing out) each. In turn, this caused severe site-wide slowdowns and timeout errors for site visitors.

The Conclusion

For those of you who don’t need the detail below, the overall conclusion here is that while a solid plugin, YARPP may cause severe site-wide slowdown and crashing for WordPress installations running on an average server with lots of posts and lots of tags.

Site Specs

First, the site specs so we’re all on the same page:

YARPP Version: 3.3.1 initially, then 3.3.2 mid-way through timeframe
WordPress Version: 3.2.x
Pages: 90
Posts: 2400+
Categories: 50
Tags: 5,000
Server: Windows machine, running WAMP 2.0
Apache Version: 2.2.11
PHP Version: 5.3
MySQL Version: 5.1.36
Other Plugins Installed Affecting Saving Posts: 3
Caching: W3 Total Cache


We had a staff of between 1 and 3 people daily updating post categories and tags to ensure the visitors were seeing the best content for their reading, searches, general experience.

The staff experience slowness intermittently and unpredictably when saving or updating posts. This happened when updating a single post through the normal ‘Edit Post’ screen and also the ‘Quick Edit’ mode on the post list page. Trying to bulk edit more than 1 post using quick edit  usually resulted in a timeout and a blank screen or the never-ending spinning save icon.

On the front end, our site visitors would experience page hangs and slow page load times whenever a post save was happening on the back end.

Our teams experienced the same basic problem in different browsers, on different machines, with different setups, so the issue was clearly coming from how we had everything set up.

In Safari:
I’ll Hit “Submit” and the little ball next to submit will spin & spin & spin, I’ll move over to work on another window, look back, and it will have stopped spinning and will look as though I never clicked submit.

In Chrome:
I’ll click submit, the ball spins & spins… Then after a while it stops and there’s a very large 8 character column beneath “Title” that says something to the effect that “My SQL Server is gone…” generally I’ll click refresh and that clears it up for the most part…

Below the post’s title I’ll right click “View” and choose “Open in New Tab” and it’ll spin & spin then will stop with no content in the body of the tab. I tried refreshing to no avail, have to close tab and re-right click & “open in new tab” again.

Additionally, we were receiving odd errors in Firefox, Chrome, and IE, all with notices along the lines of the server having too much traffic, or the server sending a blank page, or the connection being reset.

Tracking Down the Problem

Turn off pinging

At first I searched through WordPress forums and Google for anything on “WordPress dies while saving” or “WordPress hangs while updating” or “Quick Edit posts hanging” and the like.

Most results on these pointed to some version of turning off pinging or notifying other sites on update. So, we turned off pinging for all posts and removed the pingomatic address from the general options. This gave no change in speed.

Permalinks Setup

Other results for searches on improving WordPress performance and speed generally or specifically when saving posts pointed to proper permalink setup. There’s a fair bit of documentation from WordPress and others that basically concludes, “don’t just use /%postname%/ for your permalink structure.” This is because of how WordPress handles redirecting.

Instead, we should use a structure that begins with a number–the post month, post year, post day, post id, or anything else that helps WordPress sort, search, and find the post more quickly.

This is great advice, but not applicable in my case because the site was already using a /%postid%/%postname%/ structure.

Optimize Tables

Then I thought, what if we’re just not keeping our database tidy enough? There are bunches of transactions going through every minute, maybe the tables just need to be optimized. So, I set up automatic table optimization of every table in the database every 24 hours. This gave us slight increases in speed, occasionally.

Follow the errors

Rather than continue to chase a ghost, I tasked the team with sending me actual error reports or screen captures or errors.


Sometimes we’d see a timeout error with a line number and reference to another plugin dying on issuing a php session id. Investigation showed that we didn’t need this session id in the admin area, so I updated the plugin to not make that call for admin pages. This seemed to help tremendously at first, but after a day we were back to the same incredibly slow post updates. At the least, the timeouts no longer occurred on that line in the plugin.

Generic Error


Sometimes we’d get a generic “Error while saving the changes” on the Quick Edit screen.

This didn’t help much, but at least showed us that there was still a real issue on hand.

MySQL server has gone away

Our real break came when we captured the following error:

WordPress database error: [MySQL server has gone away] insert into wp_yarpp_related_cache (reference_ID,ID,score) (SELECT…[specific long query info here] WordPress database error:[MySQL server has gone away] insert into wp_yarpp_related_cache (reference_ID,ID,score) values (6779,0,0) on duplicate key update date = now()

All other MySQL processes were working and other queries were passing through, but occasionally we would see a stack of errors that always started with these two from YARPP.

After reading through the YARPP documentation, I decided to turn off cross-relating pages and posts, turn off considering categories, and turn off considering tags. This didn’t help in a measurable way. We were still seeing 2-minute post saving.

So, I deactivated YARPP. We saw dramatic improvements immediately. The server CPU usage dropped, and more importantly, saving posts went back to a normal speed of under 15 seconds. At the same time, as a consequence, the page-load speed for visitors also increased.

After about 10 days, the site performance and saving speed has been consistently good–saving posts at under 15 seconds per. We’re also able to bulk edit posts again.


While a solid plugin, YARPP may cause severe site-wide slowdown and crashing for WordPress installations running on an average server with lots of posts and lots of tags.

It’s true that this issue may be limited to my client’s particular site/server/plugin setup. There’s no doubt that other plugins were interacting with YARPP to contribute to the slowness. However, the number of forum posts on this issue, the newest default settings for YARPP of not considering categories, and notes from the author on the intensive calculations being performed lead me to believe others may have the same problems too.


  1. This is really good info. I’m testing YARPP on a new project and I’ve had concerns about performance from the beginning.

    I’m curious to hear if you’ve found any reliable alternatives to YARPP or if you have experimented any further with a “slimmed down” implementation of YARPP to measure results against a “YARPP-less” install?

    It really is a great plugin – I’m just very concerned about performance.

    • Thanks Scott, I hope it helps. I didn’t do any testing with a ‘slimmed down’ implementation. It was causing such drastic performance problems for our editing staff that we needed to act quickly to save time, and therefore money. It’s probably important to note that the only performance loss I noticed was when posts were being saved or updated. When a post was updated, the system as a whole hung, meaning for both editors and site visitors. When no post updating was going on, we didn’t notice any performance hit from the plugin.

      As for alternatives, I made a quick switch to “Pretty Sidebar Categories,” which is not really the same thing. It simply lists some posts from the same category. In the end, our goal in using either of these plugins is to keep readers on the blog finding relevant information and feeling like it’s a valuable website. Pretty Sidebar Categories provides a way to avoid a dead end post without adding any overhead on saving or updating posts. The suggested posts may not be as relevant or site-wide, but if they keep the reader digging in, then I feel like the plugin is serving its purpose.

  2. Good to know! I am really concerned about performance, especially now that it factors in SEO.

    It reminds me of the Facebook Like button adding 2-3 seconds to the page load time.

  3. Ian Douglas says

    And yet, related posts is such an important functionality in keeping visitors onsite. What is your solution, therefore?

  4. Thanks Aaron for the description of your problems. Sorry to hear YARPP caused you this trouble.

    The YARPP FAQ includes a number of tips for making YARPP less computationally intensive. I suggest anyone interested take a look at that.

    I’m currently working with some larger site owners to better understand the performance issues and improve on them.

  5. I have been experiencing this problem for some time now, its extremely frustrating.

    I have had to turn YARPP off for all my posting sessions. I’m on an EC2 small instance, and my site has about 7000 posts all together.

    Mitcho, do you plan to fix this at all? I’m afraid I will have to abandon the plugin.

    Its caused me so many wasted hours of elance professionals trying to figure out what the problem was; I thought it was bad server config, SQL problems, other plugins….


  6. As far as I understand, the new version of YARPP comes with an improved sidebar widget. I personally haven’t updated to the latest version because I’ve modified an older version to fit my needs more specifically. The code I shared on this post is what I use.

  7. Pranav shah says

    I also faced the exact same problem. Was throwing “My sql connection time out” error.
    There were 2 problems( dont know exaclty).
    1) Yarpp
    2) Cache
    Firstly in Yarpp settings find “how only posts from the past” and decrease to 1-2 months. It was 1year previously
    Set threshold limit to 1

  8. anyone tested it recently ? still have problems this ?