Performance problem in "recommend by author" plugin

[asmecher]

The "Recommend By Author" plugin queries for an author across all journals in the installation, in all supported locales. With large numbers of authors and more than a few locales, this can get quite slow.

The issue was reported (by @ajnyga) in OJS 3.1.2; in OJS 3.2.0, the query appears to have been rewritten to be journal-constrained, which is probably not intentional.

• Fix performance issues with large data sets
• In 3.2.0, verify that the plugin correctly lists recommendations in other journals on the same installation

[asmecher]

Also reported on the forum: https://forum.pkp.sfu.ca/t/ojs-3-1-2-plugin-of-recommended-articles-of-the-author-makes-the-platform-slower/60628/2

[mfelczak]

For a multi-tenant install or an install with unrelated journals, it would be preferable to keep this plugin to be constrained by journal or to add a setting to retain this functionality.

[ajnyga]

Was this fixed for 3.3?

[asmecher]

No, I don't think there's been any dev activity on this one yet.

[asmecher]

@mfelczak, this feature currently searches OJS's author records by given and last name, looking for exact matches. This performs badly but also doesn't align with our plans for author disambiguation using ORCIDs. Do the clients who are asking for this feature tend to use ORCIDs?

[mfelczak]

Hi @asmecher, I don't have a firm sense of ORCID adoption across our hosted journals as it's not something that we currently track. We could provide some stats though if that might be helpful, e.g. checking whether the ORCID plugin is enabled.

[asmecher]

Rather than stats for existing users, I'd be curious whether editors think adopting it in place of "recommend by author" would meet that feature's need. At best, an OJS-based author list can only show the results in that single installation; using ORCiD, it'll be a global list of everything that author has written. I suspect end users interested in following an author would much prefer the latter. Editors might want the former as a "brag page" but I'm not sure it'll help researchers.

[jonasraoni]

I can confirm this plugin is a bit resource intensive. As I've a good place to test some improvements, I've assigned it to me.

[Ian-BD]

Has there much headway in improving the performance of this plugin?

We run a large multi-journal site and was having some major performance issues which we've narrowed down to this.

For now we've disabled the plugin but if you have any suggestions as to how we can make some temporary workarounds while you work on improvements that'll be greatly appreciated.

[jonasraoni]

@Ian-BD I've just had time to update a similar plugin (#8710). Last time I've skimmed the code, I saw some opportunities to optimize it, in case you get it fixed, feel free to contribute :)