Hi 
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! 
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
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
Demonstartion with Firefox DEV-Console request information
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
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?
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
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!
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 
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:
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?