Serious performance issue with regards to caching - OJS 3

One more observation that I made;

Wherever there is page-number indexing or these clicking AJAX-pull resources, there is a possibility of burdening the server.

E.g. The users page in admin panel, for example if I click a certain page number - it takes time to load the page because there are a large number of users in the database. Now, if someone is not patient enough or does not have the technical knowledge - they will constantly click that page number a lot of times expecting it to work faster. But what this is doing is creating a UNIQUE request for the resource on every click (now, this may go up-to 50 requests or even more until the server throttles).

I am not able to diagnose it accurately where my issue could possibly be arising from (maybe, you can help me better), but I am sure it is from one of these clickable instances in the admin/login panel (where people more than myself have access).

POSSIBLE FIX: Whenever someone clicks these buttons once, it should freeze all of these until the resources are completed loaded (possible through simple Javascript, if I’m not wrong). Or, maybe a deeper fix that you might understand better.

Hi @Jaimin,

Glancing over the slow query log linked above, it appears to have captured a lot of queries that by themselves are quick and harmless, but are probably getting logged because the database server is already bogged down and performing poorly, e.g.:

SELECT setting_name, setting_value, setting_type FROM plugin_settings
WHERE plugin_name = 'defaultmanuscriptchildthemeplugin' AND context_id = 1;

I think you’ll have to track down the cause of periods of poor performance by looking through your access log at times where performance has degraded. The most important thing to determine is whether some burst of activity is causing a degradation, or whether there’s an underlying data problem (e.g. tens of thousands of spam user registrations), or whether your database server is just under-resourced. Unfortuantely I can’t do any of that from here.

Thanks,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

Thanks for your reply. Could you share how I could monitor which script is causing a problem? I have no idea how to get to the root of it. Is there any such setting I could change in PHP to monitor where it is coming from.

Also, just a suggestion - I think might be a simple suggestion to implement but could go a long way; if you can add these frontend fixes to paging elements in the panel in the upcoming versions so that it only enables back once the data has completely loaded, could help efficiently handle data better. Maybe?

Best Regards,
Jaimin

Hi @Jaimin,

Could you share how I could monitor which script is causing a problem?

This is more of a web server question than an OJS-specific question; you might find good general guidance e.g. on StackOverflow. But if you have a reliable monitoring tool that can tell you when the server is responding well, you should be able to identify the start of a period of time when the server is performing badly. Then look at the access logs for that time period, and watch for patterns.

I think might be a simple suggestion to implement but could go a long way; if you can add these frontend fixes to paging elements in the panel in the upcoming versions so that it only enables back once the data has completely loaded, could help efficiently handle data better.

I’m afraid we can’t allocate dev time that way – we have a lot of competing priorities shared by a small number of devs. If several users report that e.g. paging on the user lists performs poorly, then we might be able to look into it – but the solution will probably be to improve the performance bottleneck, rather than disabling controls. I think you’d be best served trying to identify a specific bottleneck or data problem. That’s not something I can do remotely, though.

Thanks,
Alec Smecher
Public Knowledge Project Team