[Plugin: Yet Another Related Posts Plugin] YARPP Performance

Hi @exxonster,

Thanks for taking a look at YARPP and thanks for the great question. ^^ Two responses: (1) Yes, YARPP can work great with large blogs as its results are cached by caching systems (which you should use anyway!) like WP-Cache or SuperCache. (2) That being said, the algorithm itself has some room for optimization and I’m currently working on a new version which will rewrite the main query to be better optimized (no more joining of temporary tables, in case you’re a mysql buff).

mitcho

I have a blog has over 20k posts. When using YARPP, the page load is very very slow. usually every page load is under 2 seconds, when use this, the page load is near one minutes even more. so I disabled it.
Hope the query method can be improved in the next release.

Hi @cdrplum — I have a new version of the algorithm which should be dramatically faster and less memory-intensive… I would greatly appreciate it if you could beta it. Please email me and I will send you the beta.

mitcho

I’m also interested in testing the new code. My blog stopped responding after installing the plugin, so I disabled it. I’m emailing you my address.

Thanks for your effort ??

I just tried the new 2.1 version, hoping it would help with the performance problems we had with 2.06. Alas, it brought the server to a crawl again.

The site I tried it on has 5400 posts, about 200 categories, and a couple thousand tags (and uses WP Super Cache of course). It runs on a quad core Xeon with 4G of RAM, and CPU and which serves about a million hits per day, all while keeping CPU utilization hovering at about 5-10%. When I turn on YARRP, CPU goes immediately spikes to 90% and the site becomes unusable.

Any suggestions for how we could optimize the query that YARRP performs? Perhaps additional indexes, turn types of matching off, etc..?

@distobj – Thank you for trying out YARPP and letting me know about this issue. This is the second report I’ve heard of poor performance under 2.1, though that user installed it for the first time (I believe).

What options are you using for your “relatedness”? Are you displaying on single pages? RSS? Is your traffic particularly RSS-heavy? Do you feel the performance is much worse than with 2.0.6? Are you using WP-SuperCache?

I would like to help resolve this issue for you and for others very quickly. If you could email me I can build a debug version for you which may help identify this issue.

Thanks again–

mitcho

Hey. Thanks for the prompt response.

I’ll answer here in case my answers are useful to others.

For “relatedness”, we have everything selected with extra emphasis on the body content as well as “require at least one tag in common”.

I turned off RSS support only because I hadn’t had a chance to see how it worked.

Performance was “worse” than with 2.06 in the sense that 2.06 took about 15 minutes to bring the server to its knees (during almost peak traffic) whereas 2.1 brought it down almost immediately despite being tested during off-peak hours. That’s not entirely an apples-to-apples comparison though, because I’d done lots of MySQL tweaking in the meantime.

Yes, we’re using WP-Supercache.

Even CommentLuv on other sites is failing to access my RSS feed with 2.1 and its RSS option turned off. I’m also using SuperCache.

I have performance issues too. The table is “locked” and the blog is unaccessible while it performs the query.

Blog has 1000 posts, 70 categories and 5000 tags.

The options I have are:

Titles: consider
Bodies: consider
Tags: require at least one tag in common
Categories: require at least one category in common

Hi all,

Thank you very much for your reports. It’s disappointing to hear that the 2.1 queries are slower than 2.0.6 (even though I thought I had only made them faster) and hope to improve this situation quickly.

I would like to know, if any of you could try this out, whether it’s the tags + categories that slow things down so much or the fulltext title + body checks that are so slow. If any of you could try turning off title + body or turn off tags + categories and get any sense of the performance, I would appreciate that.

I’m also curious about the RSS being slow, even if the RSS display is turned off… (@michaelpark) there is a quick check (get_option) which runs when an RSS feed item is constructed, but that should be a very quick transaction… are you seeing any YARPP output even though you chose to turn off the RSS auto display option?

Thank you all in advance for your continued support and reports!

mitcho

Regarding RSS, it acts as if it’s not turned off even when it in fact is unchecked on its options page.

I don’t have other performance issues.

Thanks.

Mike

@michaelpark – I see, so the RSS display is just being turned on, regardless of your setting… let me know if you’re willing to try out a debug version which will help me understand why the RSS related posts are being displayed regardless of the option.

Sure, give me the link and tell me what to do.

//

I’ve just done a fair bit of testing, and when I enable tags & categories (at “consider”), I see the widest variance in CPU utilization by the mysql daemon. For bodies and titles, I’m seeing anywhere from about 0.6-1.1 sec, but for tags/categories, it can consume anywhere from 1 to 5 seconds depending upon the particular post I’m testing on.