Loading of mrbs very slow

jberanek commented 4 years ago

hi

i realise the loading of bookign system very slow .

especially when when i first load the day, week or month page .

even when i click to create entry , please hrlp

here are info to help with your suport

i use xampp on windows 10 , 8Gbg ram server
i set xampp php to have 1G buffering memory
db us innoDB
latest verson of mrbs /php
it takes 1 -2mins to load any pages
i tested both on local server and remote also same
i adjusted everything but still load slow

for the mrbs , i just wish to use as a simple app, see calender and book slot, is there anyway to disable any other part of mrbs script to allow faster loading?

pls help

Reported by: *anonymous

Original Ticket: mrbs/support-requests/1976

jberanek commented 4 years ago

Things to try:

(1) If your server is not connected to the internet try setting in your config file

$zoneinfo_expiry = 0;

(2) Have a look in your PHP error log to see if there are any clues.

(3) Have a look at the Network tab in your brower's development tools to see what's taking the time.

Original comment by: campbell-m

jberanek commented 4 years ago

I realise the JS file are caused the slow loading

function
datepicker
general
refresh

All the top took 25 sec to load on the top the day, week, month which took at least 13 s to load

Any further advise?

MY server is connected to internet

Original comment by: *anonymous

jberanek commented 4 years ago

All those files are in fact PHP files (eg refresh.js.php). Try doing a hard refresh on your browser to clear the cache and if those files are still slow to load but the pure JavaScript files, eg the jquery file, are fast, then I suspect that your PHP system is running slowly for some reason. Are you having problems with other PHP applications?

Original comment by: campbell-m

jberanek commented 4 years ago

hi other php file which is using js and jquery files are loading pretty fast.

i am really puzzled , every click on the mrbs causes a "slow lag"

which part of xampp could i be looking in at to try on the setting would you suggest?

Original comment by: *anonymous

jberanek commented 4 years ago

Are you able to send me a private message with a link to your site please?

Original comment by: campbell-m

jberanek commented 4 years ago

Hi,

I am also facing the same issue. From the last week onwards my MRBS also loading very slow on day, week, month pages. Please advise

Original comment by: *anonymous

jberanek commented 4 years ago

If your site is accessible over the internet, would you be able to send me a link to it please in a private message?

Original comment by: campbell-m

jberanek commented 4 years ago

Thanks for the private message. I note that your site is not accessible over the internet. However I also see that you are running MRBS 1.5.0. Could you install the latest release please (1.7.4.1) and see if you still get slow loading? There's no need to upgrade your existing 1.5.0 system. Just install 1.7.4.1 in a different web folder and using a different database table prefix. Knowing whether the latest release has the same problem will help the investigation.

Original comment by: campbell-m

jberanek commented 4 years ago

Thanks. Will try installing new version.

Original comment by: ram1988

jberanek commented 1 year ago

Here I experience probably a similar issue. I'm wondering if the big number of requests could be one of the reasons. If many links were already retrieved from the browser cache most times the loading times are quick. If more (I guess now more than 20) requests are made, the server suddenly start responding very slow here. For every extra request above 20, another extra 30 seconds waiting time seems to be added. (so sometime you have to wait multiple minutes for the showing of a page is completed. Remarkable is that it does not time out). See below for an example from the Network tab of the browser Developer tool. The slow downs happen also when navigating to next/previous day, after a number of quick loads, then a slow load (about 30 sec) happens, and next ones are quick again.

In WordPress I see the same issue, but there the slow down happens very seldom. (of course this indicates that the server is also doing something unexpected, because these slow downs in steps of 30 sec feel not normal for me).

Some observations about the requests done:

the expire time is 30 min, rather short for files that never change. The ?v= ensures already that at upgrades the newest version is requested? So, longer expire times could reduces number of requests already (not the first time of course) significantly?
a lot of little files are served from .php files. What about joining them all or the most in one such call? Less requests makes pages quicker. And if properly cached, they are not loaded for a long time as well :-) Does even a couple of them not need php at all? For having comments php feels a bit over done. Eventually one version that is area dependent, and other request that is generic?

From my hosting I got already the question if the sessions where stored on disk. I believe the sessions are stored in the database. Or are there settings that let it store on disk in stead of database? using where WordPress for authentication and sessions.

Regards, Klap-in

(more readable in a monospace font..:)

index.php                                         200        document   Other            4.2 kB         233 ms      Stylesheet
jquery-ui.structure.min.css?v=1672926881          200        stylesheet index.php        (memory cache) 0 ms        Stylesheet
jquery-ui.theme.min.css?v=1672926884              200        stylesheet index.php        (memory cache) 0 ms        Stylesheet
datatables.min.css?v=1672926881                   200        stylesheet index.php        (memory cache) 0 ms        Stylesheet
flatpickr.min.css?v=1672926892                    200        stylesheet index.php        (memory cache) 0 ms        Stylesheet
select2.min.css?v=1672926884                      200        stylesheet index.php        (memory cache) 0 ms        Stylesheet
mrbs.css.php?v=1672926880                         200        stylesheet index.php        (memory cache) 0 ms        Script
init.js.php?v=1672926890                          200        script     index.php        260 B          71 ms       Script
jquery-3.6.1.min.js                               200        script     index.php        89.9 kB        70 ms       Script
jquery-migrate-3.4.0.min.js                       200        script     index.php        13.6 kB        48 ms       Script
jquery-ui.min.js?v=1672926880                     200        script     index.php        114 kB         90 ms       Script
functions.js.php?area=3&v=1672926890              200        script     index.php        15.0 kB        1.0 min     Script
general.js.php?area=3&v=1672926890                200        script     index.php        8.6 kB         2.5 min     Script
datepicker.js.php?area=3&v=1672926890             200        script     index.php        6.1 kB         30.23 s     Script
flatpickr.min.js?v=1672926890                     200        script     index.php        48.7 kB        77 ms       Script
select2.full.min.js?v=1672926884                  200        script     index.php        79.5 kB        84 ms       Script
nl.js?v=1672926889                                200        script     index.php        1.1 kB         66 ms       Script
nl.js?v=1672926892                                200        script     index.php        2.1 kB         65 ms       Script
index.js.php?area=3&v=1672926890                  200        script     index.php        5.3 kB         1.5 min     Script
refresh.js.php?area=3&v=1672926890                200        script     index.php        9.5 kB         2.0 min     Script
resizable.js.php?area=3&v=1672926890              200        script     index.php        31.9 kB        94 ms       Stylesheet
mrbs-print.css.php?v=1672926880                   200        stylesheet index.php        (memory cache) 0 ms        Document
bar.html?type=add&isVaultLocked=false&theme=light (canceled) document   notification Bar.js:472         0 B        1 ms        Document
bar.html?type=add&isVaultLocked=false&theme=light 200        document                    1.7 kB         5 ms        Script
bar.js                                            200        script     bar.html?type=add&isVaultLocked=false&theme=light        7.5 kB        4 ms        Stylesheet
bar.css                                           200        stylesheet bar.html?type=add&isVaultLocked=false&theme=light        4.2 kB        4 ms        Image
icon38.png                                        200        png        bar.js:79        857 B          3 m

Original comment by: *anonymous

jberanek commented 1 year ago

I suspect that the delays are not due to the number of requests (though your comments are valid, but will only make a marginal difference), but to the search of the database and particularly the retrieval of display names, especially if you have a lot of bookings.

MRBS prefetches in the background the pages for the next and previous days, so if you don't click on those links for a while they will be quick. But if you click on them immediately the page will load slowly.

Are you using registrations and are you using LDAP with a big directory? If so, try setting $auth['show_registrant_names_in_calendar'] = false; in your config file.

Original comment by: campbell-m

jberanek commented 1 year ago

From my hosting I got already the question if the sessions where stored on disk. I believe the sessions are stored in the database. Or are there settings that let it store on disk in stead of database? using where WordPress for authentication and sessions.

The sessions are stored in the database and there isn't a setting to allow them to be stored in the file system.

Original comment by: campbell-m

jberanek commented 1 year ago

no, I do not use LDAP. I use WordPress for authentication (less than 100 users) and session. But before it was using config-authentication with a couple of users for a long time. There I observed the same issue.

Original comment by: klap-in

jberanek commented 1 year ago

Perfect! Then I can remove that cause from the list.

Original comment by: klap-in

jberanek commented 1 year ago

There was still, something in WordPress I guess, using session files from disk. After installing https://wordpress.org/plugins/wp-native-php-sessions/ and logging in again, I cannot reproduce the slowness anymore.

Original comment by: klap-in

jberanek commented 1 year ago

Your site, using the link you sent me by PM, was very slow indeed just now the first time I tried it, but when I tried it the second time a few seconds later in a different browser it behaved as I would expect.

The first time it took a few minutes just to get to the login screen. I don't think the problem is anything to do with MRBS, as all that happens to get as far as the login screen is checking the MRBS tables and initialising WordPress. I suspect the problem is something to do with starting up WordPress or PHP or the web server.

Original comment by: campbell-m

jberanek commented 1 year ago

I've just tried your site again and it's taking 15 to 22 minutes to get to the MRBS login screen!

Original comment by: campbell-m

jberanek commented 1 year ago

Have you tried looking at the network/timing debug windows in some browsers?

Original comment by: plbplb

jberanek commented 1 year ago

Yes, see the output above.

Original comment by: campbell-m

jberanek commented 1 year ago

Hi, I am also experiencing a very slow performance too Any update on this? Thanks, Sam

Original comment by: *anonymous

jberanek commented 1 year ago

My set up is:

Configuration details MRBS version MRBS 1.11.0 Database schema version 82 Database local schema version 1 $auth['type'] db $auth['session'] php Server details Database MariaDB Server 10.1.48-MariaDB System Linux web232.extendcp.co.uk 4.18.0-425.13.1.el8_7.x86_64 #1 SMP Tue Feb 21 04:20:52 EST 2023 x86_64 Server time 9 Mar 2023, 11:58:50 GMT Server software Apache PHP 8.0.25 Extensions Core, FFI, PDO, PDO_ODBC, Phar, Reflection, SPL, SimpleXML, Zend OPcache, bcmath, bz2, calendar, cgi-fcgi, ctype, curl, date, dba, dom, enchant, exif, fileinfo, filter, ftp, gd, gettext, gmp, hash, iconv, imap, intl, json, ldap, libxml, mbstring, mysqli, mysqlnd, odbc, openssl, pcntl, pcre, pdo_dblib, pdo_mysql, pdo_pgsql, pdo_sqlite, pgsql, posix, pspell, readline, session, shmop, snmp, soap, sockets, sodium, sqlite3, standard, sysvmsg, sysvsem, sysvshm, tidy, tokenizer, xml, xmlreader, xmlwriter, xsl, zip, zlib

Original comment by: *anonymous

jberanek commented 1 year ago

Are you able to give a link to your system, maybe by private message?

Original comment by: campbell-m

jberanek commented 1 year ago

Hi,

I managed to get the issue resolved by speaking to the server administration team where it is hosted...

They added this line to the php.ini file

"session.save_path" = "/tmp"

and set to PHP 7.3

Obviously this may depend on the exact server but certainly worth discussing with your host if you face a similar issue.

Thanks, Sam

Original comment by: *anonymous

jberanek commented 1 year ago

Mmmm. Very strange. I don't understand why either of those changes would make a difference. PHP uses a custom session handler that stores sessions in the database, so I can't see that the value of session.save_path would make a difference. Nor can I see why downgrading from PHP 8.0 to 7.3 would make a difference either.

Original comment by: campbell-m

jberanek commented 1 year ago

Have you made any changes to MRBS?

Original comment by: campbell-m

meeting-room-booking-system / mrbs-code

Loading of mrbs very slow #2671