Being a small publisher using OJS is very angst inducing. It is a feeling of “what has stopped working since last time” every time we are ready to publish a new issue.
Last time we published something was in April or May. The site was running well and was at least somewhat “snappy”. This past Thursday we were ready to publish another issue and now OJS is so slow it is painful. Every press of a “button” takes several seconds. Anywhere from 4 all the way up to 20 seconds. Publishing an issue used to take about an hour all in all, but now it takes literally days because every time I press a button it takes so long I have to do something else while it loads in.
Analysis using webdev PageSpeed Insights gives us a grade of “fail”.
Time To First Byte is at 7s.
Largest Contentful Paint is at 7.8s.
First Contentful Paint is at 7.4 seconds.
And obviously, our hosting provider says it has nothing to do with them.
The only recommendation they could offer was to switch to MySQL 8.X for the database.
They also told me to look for anything fetched from external sources that might take time, but does OJS do that?
They also increased our RAM allotment, but I have not noticed any improvement.
So can someone visit our site, https://ojs.novus.no, confirm that it is much slower than it should be and perhaps offer a suggestion as to where we should start looking for the culprit. I have no way of checking the server side of this.
A 7s time to first byte is not typical and there definitely should be a way to resolve it. I don’t think a MySQL update will fix it, and I’m hesitant to recommend throwing changes at it without analyzing the cause first.
Regards,
Alec Smecher
Public Knowledge Project Team
It’s a bit difficult to diagnose the cause of this type of problem just from the symptom (slowness), without access to the server. So I’ll comment on some possibilities that I’ve seen occur in other OJS.
Apparently the bottleneck is associated with the database server.
Do you have thousands of users registered in the database of this OJS? In particular, those users who we’ve noticed don’t look like real people (e.g. Collaborative list of spam user patterns ). Depending on the number of users and the computer resources available, this can negatively affect the performance of the OJS.
Check whether the “Most read articles by the same author(s)” plugin used in 3 journals may be affecting the performance of this OJS. For example, try disabling it in all of them and see if performance improves.
Check the server access logs to see if there are many bots indexing the journal and if there are any of them accessing the journal at very short intervals.
If the database used is MySQL/MariaDB, check that all the tables use Innodb.
Does your OJS use shared hosting? If so, it’s likely that your provider adds restrictions beyond memory and CPU usage. We, for example, host the OJS on a VPS server for better visibility and to avoid headaches with the restrictions mentioned.
The delay in publishing an issue may be associated with sending an e-mail notifying users. The number of users and the time it takes to send each message in your current configurations count for a lot. Newer versions of OJS send messages in the background and will probably provide a much better experience.
If the database used is MySQL/MariaDB, check that all the tables use Innodb.
Just wanted to highlight this particular recommendation @abadan makes! You can check what storage engine your database uses by looking through the database dump for ENGINE=InnoDB clauses in the CREATE TABLE statements. All the tables should be InnoDB, and in particular if you have a mix of InnoDB and MyISAM, it’ll bring your performance way down.
Regards,
Alec Smecher
Public Knowledge Project Team
“Do you have thousands of users registered in the database of this OJS?” No. Not even close. We have 20 registered users. No spam users either. Used to get lots of spam users, but that has not happened for a good while now. We merge them all into a deactivated spam user if we discover them.
Disabled “Similar articles” plugin for all journals. No noticeable difference.
I am not eager to disable “Other articles by author” plugin as we consider this an important feature. After 4 years this has still not been optimized to work on shared hosts (which must make up a very high percentage of OJS installations)?
I see that PKP is constantly concerned that OJS is easily installed and maintained, so that as many journals as possible can use it.
I don’t know how much it has improved or not on shared hosting, as I stopped using it for OJS more than a decade ago. However, my comment was about the other side: how some providers have various additional limits, such as the number of open files, low IO limits, restrictions on database use, etc. which means that, even if there is enough memory and CPU, there are often other bottlenecks. Perhaps your provider can help you identify where the specific bottleneck is?
Our host just says they don’t know the system and seem wholly uninterested in helping figure it out. Moving to a more expensive host, or a more expensive plan with our current host just to get this plugin working is not feasable.
It would be helpful if you could confirm whether the “other articles by author” plugin is responsible by disabling it for a moment and checking the request times. Otherwise we’ll have to look for other causes.
Regards,
Alec Smecher
Public Knowledge Project Team
I have disabled it for all journals. No noticeable difference. Still glacial speeds.
I will try creating a MySQL 8.X database to see if it makes a difference.
Same host, different server. Trying to import my sql-dump into a new database through phpmyadmin times out every time. Any tips for settings? Upload and memory set to 512mb in PHP settings. Dump file is 140mb.
I think that might explain the poor performance – OJS is known to perform better when the database server and PHP server are on the same machine. This is because OJS executes a lot of queries in page building, and the overhead of connecting to a remote server can be considerable. If it’s an option to move to an environment with the database server running on localhost, it should improve things. (We’ll be improving this somewhat in 3.5.0, but probably not 100%.)
For phpmyadmin, at a certain point it’s just best to either connect to the database remotely through a MySQL client, or to use a ssh session to load/dump large databases.
Regards,
Alec Smecher
Public Knowledge Project Team
It had explained it had it not been for the fact that the site was not by any means this slow before the summer, and now after the summer break, without us changing or adding anything to the site, it is almost useless because of how slow it is… Oh. BTW our OMP site is also slow. Fetching the catalogue page takes about 30 seconds.
Update. Suddenly, after this past weekend, the site was fast again. We never even managed to successfully export and import the database onto the MySQL 8 server (why is phpmyadmin such a piece of junk). So all that time wasted looking for a problem that was apparently out of our control.
We never even managed to successfully export and import the database onto the MySQL 8 server (why is phpmyadmin such a piece of junk).
I’ve exported and imported larger databases with PHPMyAdmin. I’ve also suffered in other cases due to host configuration. Your difficulties are probably due to limits imposed by your provider and not software limitations.