Admin: Journal-Settings: 'Sections' tab loads over 60 seconds!

Hi :slight_smile:

I use OJS 3.1.0_1

Iam @ /index.php/journal/management/settings/context and want to click the “Sections” tab to manage all sections. When I click it, the Loading animation comes up and stays there abount 1 minute before content is showing up.

Why the delay here? How to speed it ip?

It loads: index.php/journal/$$$call$$$/tab/settings/journal-settings-tab/show-tab?tab=sections

Thanks in advance! :wink:

Do you have php.error log records available? If yes, post them here so we can see.
Are you sure that your hardware resources are sufficient for OJS to run properly?

Thanks

There are no errors and this is the only page that loads that slow.

The webserver is a VM in an powerful Esxi environment. It shouldbbe suficcent :wink:

Gruß,
R. Kluth

I have had cases in VM and especially in Hyper V that CentOs from time to time is very slow. Please check in your settings do you have sufficient RAM allocated. Also, please check in php.ini how much RAM scripts can use.

We still have this issue. Different page.

It happens in Joutnal → Back issues (/index.php/joutnal/manageIssues#backIssues => call: /$$$call$$$/grid/issues/back-issue-grid/fetch-grid?_=1521538540122)

It time out (max_exec-time is currently 200 secs). But I dont see the problem in server.

Here some specs:

Host-CPU: Intel(R) Xeon(R) CPU L5640 @ 2.27GHz
Host-RAM: 4GB

PHP-Settings: https://screenshots.firefox.com/P6C8I6cct5goKqv8/ojs.openagrar.de

Do you need an slowlog? Or it’s the “old” PHP-Version?

i have the same problem in the Settings-Journal menu, only when i tried to access, this take about a minute or more, why this? y got this problem since OJS 3 first launch, at this moment had the latest versión and my server is fast enough, any solution ???

Which PHP Version? My tests confirmed that PHP7 indeed speedup things.

Gruß,
R. Kluth

i have php 7.2, i think its ok or not?

Yep, thats ok.

No ideas left, I hope the devs can answer with a hint.

Gruß,
R. Kluth

Hi @alienmau,

Can you explore the problem in more details? E.g. with browser’s tools for developers in Chrome there is a network tab that might contain a hint which request is occupying that time

So. Now we have PHP 7.2 and 8 cores & 8GB RAM. PHP-FPM enabled.

The tab still needs long to load and the PHP process is at 100%. Is it possible to multi-thread that process? So it can take more cores to generate the page?

OJS 3.1.0.1

Additional infos:

I’ve attached two gifs which show the problem. The shown journal is loading after some time. But we have journals with even more back issues which timeout on loading the back issues.

Again, while loading, the PHP process is at 100% cpu usage (/out of 800% on an 8-core system). Is PHP limited to one core only?

Why does nobody else have issues with the back-issue page load times?

Demonstration
20190524_065137

Demonstartion with Firefox DEV-Console request information
20190524_065554

Hi @Commifreak,

How many sections does your journal have? How many section editors are assigned to each section, in general? It’s very unusual for things to take that long, and the queries involved are not complex.

(PHP requests run single-threaded, and whether or not simultaneous requests get handled in a multi-threaded way will depend on your SAPI, so I’m not surprised you’d max out at 100%.)

Regards,
Alec Smecher
Public Knowledge Project Team

Hi,

thanks for your answer :slight_smile:

The journal has 13 sections with No assigned editors. But we have many back issues for this journal. Opening the back issues page takes some time.

Please take a look on the screenshot attached to get a few stats on our back issues. Maybe you can reproduce the issue?

Screenshot_2019-06-18%20Issues

EDIT: Sorry, I have to clarify the current issue. Originally the section tab needed more than 60 seconds which improved after switch to PHP7. However the MAIN problem (opening back issues) still exists. So the current problem here is the back issues page takes years to load. Wihtout any obvious reason.

Hi @Commifreak,

What is your “items per page” setting in your Appearance settings tab? If you’ve increased it considerably from defaults, try setting it e.g. to 20 to see if that affects the load time.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi,

the setting was 25 items per page. I set it to 1 but it doesnt change a thing.

I would say this setting only applies for the frontend? Im talking about the backend. And as it seems, the back issues page in the backend always loads ALL items.

Is it possible to get an similar data environment as we have as in the picture shown? I dont see the reason for that long loading times (currently 200 seconds to open back issues page).

Current env:

OJS 3.1.0.1 (update is planned)

OS-Plattform Linux
PHP-Version 7.2.19-1+ubuntu18.04.1+deb.sury.org+1
Apache-Version Apache
Datenbanktreiber mysqli
Version des Datenbankservers 5.5.62-0ubuntu0.14.04.1

Hi @Commifreak,

Ah, you’re right, the paging settings don’t apply to that page. Would you mind applying this patch? See if a shorter list of items improves performance.

diff --git a/controllers/grid/issues/BackIssueGridHandler.inc.php b/controllers/grid/issues/BackIssueGridHandler.inc.php
index 3c25736..5a4ff9d 100644
--- a/controllers/grid/issues/BackIssueGridHandler.inc.php
+++ b/controllers/grid/issues/BackIssueGridHandler.inc.php
@@ -83,7 +83,8 @@ class BackIssueGridHandler extends IssueGridHandler {
 	 */
 	function initFeatures($request, $args) {
 		import('lib.pkp.classes.controllers.grid.feature.OrderGridItemsFeature');
-		return array(new OrderGridItemsFeature());
+		import('lib.pkp.classes.controllers.grid.feature.PagingFeature');
+		return array(new OrderGridItemsFeature(), new PagingFeature());
 	}
 
 	/**
@@ -92,7 +93,7 @@ class BackIssueGridHandler extends IssueGridHandler {
 	protected function loadData($request, $filter) {
 		$journal = $request->getJournal();
 		$issueDao = DAORegistry::getDAO('IssueDAO');
-		return $issueDao->getPublishedIssues($journal->getId());
+		return $issueDao->getPublishedIssues($journal->getId())->toArray();
 	}
 
 	/**

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like

Hi,

this is MUCH better! I’ve set the Items per page dropdown to “10” which still needs 10 seconds to load (what huge calculations are made here?!) but this is a nice workaround for now!

Anmerkung2

Hi @Commifreak,

Is it possible that you’re missing an index on the published_submissions table? If you’re handy with MySQL, check to see if it matches mine…

mysql> show indexes from published_submissions;
+-----------------------+------------+-------------------------------------+--------------+-------------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table                 | Non_unique | Key_name                            | Seq_in_index | Column_name             | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-----------------------+------------+-------------------------------------+--------------+-------------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| published_submissions |          0 | PRIMARY                             |            1 | published_submission_id | A         |           6 |     NULL | NULL   |      | BTREE      |         |               |
| published_submissions |          0 | published_submissions_submission_id |            1 | submission_id           | A         |           6 |     NULL | NULL   |      | BTREE      |         |               |
| published_submissions |          1 | published_submissions_issue_id      |            1 | issue_id                | A         |           2 |     NULL | NULL   |      | BTREE      |         |               |
+-----------------------+------------+-------------------------------------+--------------+-------------------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
3 rows in set (0.00 sec)

Regards,
Alec Smecher
Public Knowledge Project Team

Hi!

Yes, Iam handy with MySQL. Unfortunately, there is no difference :frowning:

STATISTICS

SHOW INDEXES FROM published_submissions
Table Non_unique Key_name Seq_in_index Column_name Collation Cardinality Sub_part Packed Null Index_type Comment Index_comment
published_submissions 0 PRIMARY 1 published_submission_id A 10041 \N \N BTREE
published_submissions 0 published_submissions_submission_id 1 submission_id A 10041 \N \N BTREE
published_submissions 1 published_submissions_issue_id 1 issue_id A 5020 \N \N BTREE

As said, PHP is at 100% while rendering that page:

Anmerkung3

Another interesting thing: I watched the MySQL Proccesslist via SHOW PROCESSLIST;.

While the page is loading, there a only some queries in one second. The most of page loading time, there is no running query!

SHOW PROCESSLIST
Id User Host db Command Time State Info
57370 ojs 192.168.205.31:51644 ojs-test-1804 Sleep 0 \N

So, what is OJS querying here? Maybe the file system, specially the files_dir maybe?