OJS User Search Slow After Upgrade to 3.5 Performance Troubleshooting Guide

Introduction

If your journal recently upgraded to OJS 3.5 and the user search has become noticeably slow, or stops returning results altogether, the problem is usually not a simple configuration mistake. In many cases, the root cause sits deeper: in how OJS 3.5 handles user-related database queries, especially after an upgrade from an earlier version where the user table has grown large over time.

Journal managers rely on the user search to assign reviewers, invite editors, and manage roles. When the search takes several minutes or times out completely, the editorial workflow stalls. This article explains why user search performance degrades after upgrading to OJS 3.5 and provides a safe, step-by-step approach to diagnosing and resolving the issue.

Problem Overview

After upgrading from OJS 3.4 to OJS 3.5.0-4, some journal managers report that searching for users by role returns no results or triggers an error. The user list page under Settings > Users & Roles takes a long time to load, and searching by email or name can take several minutes. In more severe cases, PHP-FPM processes time out after 300 seconds or more, and the search never completes.

This behaviour has been confirmed on the PKP Community Forum by a user who shared PHP-FPM timeout logs showing execution times exceeding 305 seconds for basic user search queries. The issue appears more frequently on installations with a large number of registered users, where the underlying database queries struggle to complete within a reasonable time.

Why This Happens

The user search performance issue in OJS 3.5 is primarily linked to how the application constructs database queries when retrieving user lists. Several technical factors contribute to the slowdown:

Database Query Complexity

OJS 3.5 uses a sophisticated user search query that performs multiple LEFT JOIN operations across several tables: users, user_settings, user_interests, controlled_vocab_entry_settings, user_user_groups, and user_groups. When the users table contains thousands of records, this multi-join query can become expensive, especially if the database server has limited resources or missing indexes.

Individual Permission Checks

A notable source of slowdown identified in OJS 3.5 is the canLoginAs and canMergeUsers permission checks. These properties run individual queries against each user in the result set, rather than being calculated efficiently in a single batch query. On installations with many users, these repeated individual queries can consume most of the total response time.

LIMIT and OFFSET Performance

The user search uses LIMIT and OFFSET for pagination. When the underlying query involves multiple joins and tables without the right indexes, MySQL or MariaDB may scan a large number of rows before applying the LIMIT, which causes long execution times even when only 25 results are requested per page.

Post-Upgrade State

After an upgrade, the database schema or indexes may not be fully optimized for the new OJS version. Some installations may also have accumulated orphaned or duplicate records in user-related tables over time, which add to the query load.

Common Causes

Based on reports from the PKP Forum and the OJS GitHub issue tracker, the most common causes of slow user search in OJS 3.5 include:

• Missing database indexes on columns frequently used in search JOIN conditions, such as the user ID column in user_settings, submission ID in submission-related tables, and user group ID in user_user_groups.
• Large user tables with thousands or tens of thousands of records, especially when the table has grown over multiple OJS versions without maintenance.
• PHP execution timeout set too low relative to the query duration, causing PHP-FPM workers to be terminated before the query completes.
• Server resource constraints, including insufficient RAM, slow disk activity, or an underpowered database server.
• Inefficient permission queries: canLoginAs and canMergeUsers in OJS 3.5 run slow individual checks per user.
• Shared hosting limitations, where database resources are shared and throttled, making complex queries slower than on a dedicated environment.
• Mixed database engine types: user-related tables running on different storage engines, for example some InnoDB and some MyISAM, can affect JOIN performance.

Troubleshooting Steps

1. Check the PHP and OJS Error Logs

Before making any changes, review the logs to confirm that the user search is the source of the slowdown and to see the actual error messages.

Check the PHP error log through your hosting control panel or the default PHP-FPM log location. Look for entries related to execution timeout and the user search URL. A typical log entry will show a PHP-FPM child process timing out with the script path and the search URL that was being processed.

Also check the OJS error log, found inside your OJS installation under the files directory, or configured via the OJS configuration file.

2. Verify Your OJS Version and Environment

Confirm the exact OJS version from the Administration dashboard. This helps determine whether the issue is related to a known bug in a specific 3.5.x release.

Also check:

• PHP version: OJS 3.5 requires PHP 8.1 or later. Older versions are not supported and may contribute to performance differences.
• Database version: MySQL 5.7+ or MariaDB 10.3+ is recommended. Running an older database version can affect query execution plans.
• PHP memory limit: Should be at least 256MB for OJS 3.5. Check via your server’s PHP info page or the server configuration.

3. Review Database Indexes

Missing indexes are one of the most common causes of slow user search. Use your database management tool, such as phpMyAdmin, Adminer, or command line, to check which indexes exist on the following tables:

• user_settings
• user_user_groups
• user_interests

Look for indexes on columns that appear in JOIN conditions and WHERE clauses, specifically the user ID, user group ID, and setting name columns. If indexes are missing, adding them can significantly improve performance.

Before adding any index, back up your database using your hosting control panel’s backup tool or a database dump utility. Then add indexes on the relevant columns. Always test on a staging environment first if available.

4. Check PHP-FPM Execution Timeout Settings

If user search queries are timing out after a fixed period, the PHP max execution time or PHP-FPM request terminate timeout may be too restrictive for complex queries on large databases.

Check the current settings through your server’s PHP configuration. In your PHP-FPM pool configuration, look for the request terminate timeout value, often set to 300 seconds by default.

Temporarily increasing this value can help queries complete, but it should not be the permanent solution: the underlying query performance should still be addressed.

Note: increasing execution timeout on a production server without fixing the root query issue can cause PHP-FPM worker exhaustion.

5. Test Query Performance Directly

To determine whether the slowdown is at the database level or the application level, run the user search query directly on the database. Enable OJS debug mode temporarily by setting the show stacktrace option to On in the OJS configuration file, to capture the exact SQL query being run. Then test it in your database client, such as phpMyAdmin or the MySQL command line.

If the query is slow even when run directly, for example taking 80 to 90 seconds or more, the issue is at the database level and indexing or server resource tuning is the priority.

If the query runs quickly directly but is slow inside OJS, the issue may be related to application-level processing, such as the canLoginAs and canMergeUsers permission checks mentioned earlier.

6. Check for Orphaned or Duplicate Records

Over time, user-related tables can accumulate orphaned records from deleted users, duplicate user_settings entries, or stale user_user_groups assignments. These records contribute to query bloat.

Run a count check on the users, user_settings, and user_user_groups tables. Compare the counts. If user_settings or user_user_groups have dramatically more rows than the users table, there may be orphaned records that can be cleaned after a careful review.

Do not delete records manually unless you fully understand the relationships between the tables. Always back up first.

Recommended Solution

The most effective approach combines several of the checks above:

1. Start with logs to confirm the timeout and identify the exact query causing the issue.
2. Add missing database indexes, especially on the user ID column across user-related tables and on the setting name column in user_settings. This is often the single most impactful change.
3. Review PHP-FPM timeout settings to ensure they are not terminating legitimate queries prematurely, while fixing the underlying query performance.
4. Clean up orphaned or duplicate records where safe to do so, reducing the total row count the query must process.
5. Monitor server resource usage, including RAM, CPU, and storage, during user search operations to rule out infrastructure constraints.
6. If the issue persists, the canLoginAs and canMergeUsers permission logic in OJS 3.5 is a known contributor to slow user list loading on large installations. This is being tracked as a PKP issue and may require an OJS patch update or expert intervention.

What to Avoid

• Do not edit OJS core files to modify user search behaviour unless you fully understand the codebase and have tested the change on staging.
• Do not delete database records without a verified backup. User-related tables are interconnected, and incorrect deletion can corrupt journal data.
• Do not increase PHP execution time indefinitely without addressing the root query issue: this masks the problem and can exhaust server resources.
• Do not assume a server upgrade alone will fix the issue: while more RAM and CPU help, the core problem is often at the query and indexing level.
• Do not disable security checks or modify permission logic to speed up user search: this can introduce security vulnerabilities.

When to Ask for Technical Help

Consider reaching out for technical assistance if:

• You have checked logs, added indexes, and adjusted server settings, but the user search is still unacceptably slow.
• You are unsure how to safely add database indexes or test queries on your production installation.
• The journal has more than 10,000 registered users and the user search consistently times out despite optimization attempts.
• You suspect the canLoginAs and canMergeUsers logic in OJS 3.5 is the primary bottleneck and need expert-level intervention.
• You do not have a staging environment and are uncomfortable testing changes on production.

FAQ

Why is user search slow only after upgrading to OJS 3.5?

OJS 3.5 introduced changes in how user-related data is retrieved, including permission checks that run individual queries per user. Combined with complex multi-table JOINs, this can cause significant slowdowns on installations with a large number of users, especially if database indexes are missing.

Can I fix the slow user search by upgrading my hosting plan?

Upgrading hosting can help if your server is resource-constrained, but it often does not fully resolve the issue if the root cause is missing database indexes or inefficient application-level queries. Database optimization should be attempted first.

Is it safe to manually add database indexes to OJS tables?

Yes, adding standard indexes to columns used in JOIN and WHERE conditions is generally safe and reversible. Always back up your database before making structural changes, and test on a staging environment if possible.

Will a future OJS patch fix this issue?

The PKP team is aware of performance issues with user management in OJS 3.5, particularly the slow canLoginAs and canMergeUsers checks. A fix may be included in a future release, but the timeline depends on PKP’s development priorities. In the meantime, the optimization steps in this article can help improve performance.

How many users is considered a large database for OJS?

There is no fixed threshold, but performance degradation in user search has been reported on installations with 5,000 users and becomes more noticeable above 10,000 to 20,000 users. The exact impact depends on server resources, database configuration, and the presence of proper indexes.

Conclusion

Slow user search after upgrading to OJS 3.5 is a real issue that can disrupt editorial workflows, especially on journals with large user databases. The root cause typically involves a combination of complex database queries, missing indexes, and application-level permission checks introduced in OJS 3.5.

By checking server logs, reviewing database indexes, testing query performance directly, and adjusting PHP settings carefully, most journals can significantly improve user search response times. If the issue persists after reasonable optimization, the known canLoginAs and canMergeUsers bottleneck in OJS 3.5 may require expert-level attention or waiting for an official PKP patch.

References

1. PKP Community Forum: OJS 3.5.0-4 Performance Issue with User Search
2. PKP GitHub: User management performs poorly with large databases (Issue 11791)
3. PKP GitHub: Slow queries on the user management page (Issue 6991)
4. PKP GitHub: Performance issue using LIMIT and OFFSET in search users query (Issue 5288)
5. PKP Community Forum: Search users very slow
6. PKP Community Forum: Performance Issues After Upgrading to OJS 3.5.0.0
7. PKP GitHub: Add indexes for search performance (Issue 6301)
8. PKP Community Forum: OJS 3.3.0.8 User search very slow

If your journal uses OJS and needs help with performance troubleshooting, upgrades, database optimization, plugin compatibility, theme issues, or server configuration, the Open Journal Theme team can help review the issue further. Visit openjournaltheme.com to learn more about OJS maintenance and support services.