Hello,
I upgraded to OJS 302 on a test server and the front facing website works fine but the backend, once logged in, is super SLOW! One of the slowest pages to load, if it loads, is /management/settings/website. Any ideas?
Hi @hawkpf,
This can have a lot of causes – if you have access to the server, I’d suggest watching the process list to see if e.g. PHP is demanding a lot of resources, or whether it’s e.g. MySQL. Use a browser developer toolbar (e.g. Firebug for Firefox or Chrome’s developer tools) to check whether a single network request is to blame.
Regards,
Alec Smecher
Public Knowledge Project Team
I’m hosting OJS on a load balanced server. I checked the server resources, there’s plenty. JQuery seems to take a while to execute. After the page finally loads I get a couple of notifications in Chrome developer toolbar.
jquery.js:9627 [Deprecation] Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user’s experience. For more help, check https://xhr.spec.whatwg.org/.
[Violation] Added non-passive event listener to a scroll-blocking ‘touchstart’ event. Consider marking event handler as ‘passive’ to make the page more responsive.
Hi @hawkpf,
That warning is cosmetic and can be ignored.
The Chrome toolbar can show what the various requests were that built the page, and thus which caused the lagginess. It could be e.g. one of several page-related requests, or associated content (e.g. CSS and images), or CDN-based content. Determining the cause through the developer toolbar is the next step in identifying the bottleneck.
Regards,
Alec Smecher
Public Knowledge Project Team
I also had a look at this after one of our journal manager complained one day. It seems that ojs 3.0.2 backend is, in normal situations, loading around 130 small files for each page (mostly small js libraries) wich will appear sluggish anyway over connections with large response times. OJS also does not seem to support local caching of these files (maybe there is a setting I have overlooked?)
Regards,
Ingo.
Hi @ingokeck,
Have you turned on enable_minified in config.inc.php?
Regards,
Alec Smecher
Public Knowledge Project Team
I moved the test server off of our load balancer and the admin pages are fast.
Hi @asmecher,
enable_minified is on and I can confirm that javascript is served minified. The problem in this case is not the amount of data, but the many connections that need to be made by the browser to the server over a connection with large response times/latency. Usually a browser will open multiple connections to the server to ask for many files at the same time, but usually only around 6 max (you can test that yourself at http://www.spasche.net/files/parallel_connections/ ).
That means that the 130 files get loaded in 6 parallel connections, i.e. 22 files per connection. Total load time therefor is 22 x (response time + time for data transfer).
If you have a good connection with response times of a few ms the data transfer time dominates the equation. In our case the user was on a VPN that had lags of hundreds of ms. Assume a 200ms response time you get 4.4s just from the lag from the connection. And that is independent from the actual transfer speed of the connection.
I include a screenshot from our server. Actual connection latency measured with ping is around 40ms right now for me on a normal DSL. Javascript is served by apache instead via php because of caching. Sorry for the German. Latenz = latency, Startzeit = start time of request, Dauer = duration.
You can see that our server needs between a few ms and 50ms to serve a file, the connections needs 40ms (see above), so totals are between 50ms-100ms per file, makes around 2.2s lag due to connection and serving. Total time till the browser is displaying the dashboard is a bit above 3s, so if the javascript could be served in a few big files I would expect a speed-up of around 50% even in my normal case (and much more in extreme cases of people connecting over lag-rich VPNs).
Now the good thing is that if caching works, the second time the user accesses the page, most of the libraries are in the browser cache and things are much much faster - in my case 0.5s instead of 3s.
Hi @ingokeck,
If JS is served minified, then you should see a request for js/pkp.min.js which will cover the vast majority of OJS javascript, e.g. all the classes in js/lib/pkp/classes/ etc. I see that some of these are still getting requested individually (e.g. lib/pkp/js/classes/linkAction/AjaxRequest.js to pick a single example).
Are you sure the enable_minified option is turned on in config.inc.php (and not e.g. some other file), and that it’s not commented out (using a ; at the beginning)?
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher,
The request for ‘js/pkp.min.js’ is at the very end of the webpage loading process, the penultimate js library that gets loaded. ‘tinymce.min.js’ is the last one.
enable_minified is turned on and confirmed by the admin console (see screenshot).
I tried to check it on the official OJS 3.0 testdrive to see if it behaves similar (and to rule out effects of our local install settings), but could not log in with the “testdrive” password.
Hi @ingokeck,
Hmm, I can’t reproduce that behavior locally (the JS being loaded both un-minified and minified) with an OJS 3.1.0 install (this was released yesterday), and I’m fairly sure none of the relevant code has changed between 3.0.2 and 3.1.0. Looking at the builds, the master branch builds tend to take considerably longer than the 3.1.0 build, and the only relevant difference is the minification flag.
Are there any modifications to your installation? Are you using any additional code that might be responsible, e.g. a theme plugin? Can you try manually flushing your template cache (rm cache/t_compile/*.php), just in case there was outdated code there?
Regards,
Alec Smecher
Public Knowledge Project Team