OJS 3.2.1.4 slow upload of Workflow > Production files

Software Support
1

Hi all,

We recently upgraded a journal from 3.1.1.0 to 3.2.1.4, migrating it from an outdated RHEL to Ubuntu 18.04 running latest Apache and PHP 7.2 and using MySQL on a separate database server. The upgrade went well and the “php tools/upgrade.php check” confirms the code and database are on 3.2.1.4.

However, the editor began to upload their production-ready files and noticed that in the Workflow > Production step of a submission that once the file is selected and he presses “continue” it takes a looooong time (i.e. 1-2 minutes) for the process to complete. The files in question are small (<1MB) and it used to be instantaneous.

I have ensured the stacktrace and other debugging options are turned off in config.inc.php so as not to introduce extra processing.

I have reviewed patches that people have mentioned on the forums, and our code base already has the suggested code.

We have turned on “slow query” logging for the site in MySQL. The following appears in the slow query log when attempting an upload.

[03-Mar-2021 11:47:00] [pool cjds] pid 25017
script_filename = //var/www/cjds/index.php
[0x00007f293b41dd10] mysqli_query() /var/www/cjds/lib/pkp/lib/vendor/adodb/adodb-php/drivers/adodb-mysqli.inc.php:788
[0x00007f293b41dbf0] _query() /var/www/cjds/lib/pkp/lib/vendor/adodb/adodb-php/adodb.inc.php:1263
[0x00007f293b41db00] _Execute() /var/www/cjds/lib/pkp/lib/vendor/adodb/adodb-php/adodb.inc.php:1217
[0x00007f293b41d990] Execute() /var/www/cjds/lib/pkp/classes/db/DAO.inc.php:229
[0x00007f293b41d890] update() /var/www/cjds/lib/pkp/classes/search/SubmissionSearchDAO.inc.php:125
[0x00007f293b41d7e0] insertObjectKeyword() /var/www/cjds/classes/search/ArticleSearchIndex.inc.php:311
[0x00007f293b41d700] _indexObjectKeywords() /var/www/cjds/classes/search/ArticleSearchIndex.inc.php:115
[0x00007f293b41d5e0] submissionFileChanged() /var/www/cjds/classes/search/ArticleSearchIndex.inc.php:158
[0x00007f293b41d4f0] submissionFilesChanged() /var/www/cjds/lib/pkp/controllers/api/file/PKPManageFileApiHandler.inc.php:225
[0x00007f293b41d380] saveMetadata() /var/www/cjds/lib/pkp/classes/core/PKPRouter.inc.php:391
[0x00007f293b41d2a0] _authorizeInitializeAndCallRequest() /var/www/cjds/lib/pkp/classes/core/PKPComponentRouter.inc.php:257
[0x00007f293b41d200] route() /var/www/cjds/lib/pkp/classes/core/Dispatcher.inc.php:143
[0x00007f293b41d110] dispatch() /var/www/cjds/lib/pkp/classes/core/PKPApplication.inc.php:281
[0x00007f293b41d0a0] execute() /var/www/cjds/index.php:68

At this point we are considering upgrading to 3.3.0.4 on dev to see if the issue still persists. However, this would mean upgrading our PHP to at least 7.3.

Are any others seeing this problem on their 3.2.1.4 journals?

As always, any guidance is appreciated.

[Edit: I also ran the rebuild of the Search Index in the hopes it might help things, to no avail, and also verified that all tables are the expected collation.]

Cheers,
Graham Faulkner
University of Waterloo Library, Digital Initiatives

2

Hello @gfaulkner .

What values do you have at php.ini?

memory_limit
upload_max_size
post_max_size
upload_max_filesize
max_execution_time
max_input_time

What ‘php’ are you using? mod, fastgi, fpm?

is a big site?

Can you record your screen at the exact moment that happens?

Thanks

3

Hi @juanito,

We are using PHP FPM. Here are the entries in php.ini that you asked about:

memory_limit = 128M
upload_max_size = ??? (not in the .ini file)
post_max_size = 8M
upload_max_filesize = 100M
max_execution_time = 30
max_input_time = 60

It is a fairly large site in the sense it has close to a decade of publishing with over 30 issues.

Cheers,
Graham

4

Hi all, curious to know if others have experience this issue and have a proposed workaround.

Cheers,
Graham

5

For those who stumble on this ticket, the solution we ended up using was changing the database and table collations from utf8_general_ci to utf8mb4_general_ci and the character set to utf8mb4. The uploads have now returned to their former zippy selves!

Cheers,
Graham

6

I may have spoken too soon. =(

The editor reported that uploading galley files in the production workflow were still slow, and when I tested they are indeed painfully slow. The problem occurs in the “Review Details” step when uploading files for production. The confirmation eventually works, just takes a painfully long time.

Cheers,
Graham

7

Hi.

I have the same problem when I try to upload files on production section. It takes from 40 seconds to 1 minute to finish the process. I recently upgrade to version 3.3.0.6.

Regards.
Alexa

8

Hi everyone,

we are having the same issues. It appears to be associated with the OJS internal Search index.
Skipping this step, by disabling it via the hook in classes/search/ArticleSearchIndex.inc.php:143 will process the request much faster.

This is not a solution if you rely on OJS search feature.

Maybe the code can be changed to not try and index all submission galleys/files, as it is currently doing?
@asmecher Do you remember if there currently is an open issue regarding indexing speed of DB based OJS search?

Regards,

Nils Weiher

9

Hola a todos,

Tengo el mismo problema, todas las revistas están demorando demasiado en cargar, utilice la página GtMetrix para conocer el tiempo de carga y está llevando entre 24 s y más para cargar cada una de las revistas, se ha mejorado la configuración del servidor pero aun así sigue muy lento, agradezco cualquier ayuda, se está dificultando trabajar, dejo la URL para que pueda ver la demora y así me puedan ayudar a solucionarlo https://hemeroteca.unad.edu.co/, puede ingresar a cualquiera de las revistas y se demora mucho es igual en producción.

10

Thanks Nils. I followed your instructions and it immediately sped up the uploads.

I guess we will run “tools/rebuildSearchIndex.php” regularly to compensate for items not being ingested into the search index.

Cheers,
Graham

11

Hi,

Has anyone had a solution for this problem?