After upgrade from OJS 3.4 to OJS 3.5.0-4, we have observed that searching for users based on their role is not returning any results and frequently results in an error. Additionally, the user list takes a considerable amount of time to load.
Further, when searching users by email or name, the system takes a significant amount of time to fetch results.
We also suggest that when searching for users or articles, a loading indicator or message (e.g., “Search in progress”) should be displayed to inform users that the system is processing the request.
Thanks for your post. That’s an interesting suggestion. Would you mind developing it on a separate post using the “Features Request” category and following the template prescribed for those posts? This allows us to better track distinct feature requests.
Okay, I’ll create a feature request, but as you can see in the screenshot, we’re also having trouble finding users by role. Searching for users by email name is taking time.
While searching for users by role along with keywords (name or email ID), the system is taking considerable time to display results, and in some cases, no results are returned.
Additionally, when attempting to search users under the Invite to a Role option, no results are displayed.
I have been unable to identify the root cause or a suitable solution.
I have already tried adjusting PHP (max_execution_time = 600), PHP-FPM (request_terminate_timeout = 600), and MySQL settings, but the issue persists. This makes me suspect there may be a server-level or application-level limitation.
I have checked the SQL process log, and it indicates that the user’s search query is taking an excessive amount of time.
Furthermore, if I attempt to search for a reviewer to enroll an existing user, no results appear, and it keeps spinning continuously.
Could you please guide me on any best practices for handling such cases?
I have searched extensively through the forums and documentation, but I haven’t found a clear solution. To the best of my knowledge, this is currently the only obstacle I am facing in migrating to OJS 3.5.
Whenever I try to search for any user from the Users & Roles or Invite to a role section, it takes around 5 minutes to display the results. I am sharing a video recording of the activity for your reference, which demonstrates the issue and the delay during user search. Please guide me.
Hi @shantanusingh
A few months ago, I experienced a similar problem with a book portal (OMP 3.4) that I manage and use for DOI registration. The submission list was taking too long to load.
On the book details page, books with 50 or more book chapters were taking over a minute to load.
I tried several sql optimizations, (innodb buffer size etc) but none of them worked. Even, I moved the book portal to a dedicated server with 32 cores of CPU, 32GB Ram, but with SSD disk, the performans didn’t improve much. If a book has more than 50 chapters, the number of SQL queries increases significantly, which greatly increases page load times.
I think the same can be said for journals with more than 50 articles and having a large number of users.
After moving that portal to a dedicated server with an NVME disk (of course the Linux os, Virtualmin panel etc remained identical), the page load time has been reduced to 9 seconds, at least 5 times faster.
So, especially if your server has an SSD disk, I can say that you’re stuck at the I/O speed of your SSD drive (since SQL queries are not cached).
With a server using SSD disks, no matter how much optimization we do, we reach a certain point. While we wait for improvements on the software side, I think reviewing some hardware checks would benefit from a performance increase.
Uğur Koçak
Thank you for sharing your experience and suggestions.
In our case, both the application and database servers are already running on dedicated infrastructure with identical configurations (16 vCPUs, 64 GB RAM, SSD storage, and optimized MySQL settings). On the same infrastructure, our OJS 3.4 portal is running smoothly without any major performance issues.
Currently, the portal contains around 23 lakh (2.3 million) registered users, and the user search and related pages in OJS 3.5 are comparatively slower with such large datasets.
Your observations regarding storage I/O and NVMe performance are very useful and will certainly be considered for future infrastructure planning and performance improvements. However, at present, we do not have any immediate plans to migrate the infrastructure.
Dear @shantanusingh
I have deeply search at that days, and I have found that, even if my server has 128000 cpu cores, MySQL runs an SQL query per one cpu core (one query/one core).
I mean, when I click to list the users (for ex.), mysql uses only one core to list that 2.3 million users and their properties. So,
I’m not a developer, but found that the problem I faced was here:
Without using an sql server that support multiprocessors (Microsoft SQL server, or Oracles’, because even PostgreSQL doesn’t currently support it!), we are limited to one cpu core per each sql query.
We are experiencing a similar issue in OJS 3.4 as well. User search becomes very slow when selecting Role does not exist in this Journal. It appears that broader user searches are taking significantly more time to execute, and currently it takes around 3 minutes to display the results.
