Performance issue with new system (OJS 3.2.1.1)

[juliadebernitz]

Dear Community,

yesterday we went live with our first OJS 3.2.1.1 system in a German library. The performance in the Dashboard and the overall navigation performance is fine.

However loading an issue with 24 articles takes around 10 seconds, which is too long.

This is the link to the system: WLBforum

Do you have any ideas here?

Our analysis leads more in the direction of SQL database issues and not the webserver. When checking the activities via mysqladmin processlist we see some unclear SQL, which could lead to the error. Especially the Insert and the Rollback.

Update INSERT INTO controlled_vocabs
(symbolic, assoc_type, assoc_id)
VALUES
(‘submissionAgency’, 1048588, 87)

Rollback INSERT INTO controlled_vocabs
(symbolic, assoc_type, assoc_id)
VALUES
(‘submissionLanguage’, 1048588, 76)

Some server information:

Setting Name	Setting Value
OS platform	Linux
PHP version	7.3.27-1~deb10u1
Apache version	Apache/2.4.38 (Debian)
Database driver	mysqli
Database server version	10.3.27-MariaDB-0+deb10u1

RAM: first 4 GB, then 8 GB
CPU: first 2 kernels, later 4 kernels
But adding more power did not make a big difference, maybe 1 second.

We have around 270 articles in 19 issues, that are not published yet. We plan to to some update to the recent OJS version in the next weeks, but not sure if this solves the performance issues.

Looking forward for some hints or ideas
Thanks a lot
Julia

[marc]

Welcome Julia,

You don’t need 4GB and 2 kernels to run OJS with a regular journal… and 19 seconds to render home is crazy.

Some ideas in the top of my head:

• Check your DB to discover if you have been hit by spammers.
• Backup and upgrade to the last ojs3.2-stable (3.2.1-4).
• Enable and check your mysql slow query log.
• Ensure you enabled the enable_minified = On in your config.inc.php

Let’s try with this before going deeper.

Cheers,
m.

[marc]

It’s wired… Don’t know why but browser keep asking for stuff for a minute and half:

Please, anonymize your config.inc.php and send it via pastebin (or similar).

Are you sure it’s not network related? and issue with proxies or firewalls?
Did you try to navigate from the same sever via “lynx” or similar?

Cheers,
m.

PD: Looks like we don’t worry yet about the NS_BINDING_ABORTED.

[Vitaliy]

In addition:
Is SQL database on the same server as the OJS instance and they communicate through localhost?
Are there any custom modifications of OJS code or non-official plugin installed?

[juliadebernitz]

Dear @marc and @Vitaliy,

thanks a lot for your answers. These are highly appreciated.

We checked all the questions and ideas we got from you, but in the beginning nothing helped. In the end we did the update to the last ojs3.2-stable (3.2.1-4) and this solved the issue

It is now under 1 second: WLBforum

From another colleague we also got the link to this issue: OJS is very slow with a large table of contents (hundreds of items) · Issue #6511 · pkp/pkp-lib · GitHub and probably this was connected.

So thanks a lot again!
Bye
Julia

[marc]

Hi @juliadebernitz

Thanks for the feedback.

Last OJS releases are better tested and include plenty of patches, so this is usually the best starting point. Happy it helps.

The issue you link was fixed using web_cache… That is a workaround, but didn’t explains why the DB queries were too slow.

Alec made me notice that this could be also related with a mixture of DB engines. InnoDB is the recommended one.

Did it change? I mean, do you mind to check you DB to see if you only include one engine now?

[juliadebernitz]

Hi @marc,

regarding the DB nothing changed with the update. We checked the backups before the update as well.

All tables in database “ojs” are InnoDB. Only some other databases use MyISAM.

10.3.27-MariaDB-0+deb10u1 for debian-linux-gnu (x86_64)

Hope this answers the question
Julia

[marc]

Yes, thanks! it answers my question… but don’t resolve the enigma.

Anyway, let’s keep “update to last stable” as a temporary solution.

Any doubt, let us know.

Cheers,
m.