I’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.
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.
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
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.
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.
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.
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.
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.
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.