Open rafaelse opened 4 months ago
cconard96
commented
4 months ago Please enable debug mode for your user (need to be on s super-user profile). Then when on the page with the dashboard, click the SQL requests widget in the debug bar at the bottom of the screen (2nd button). Click the "Time" column header to sort by the slowest.
Can you identify the slow query(s)?
rafaelse
commented
4 months ago We didn't know about the debug mode yet, but upon following your instructions, we noticed that it seems like it isn't the database that is slowing down the loading of the dashboard, but something related to ajax requests. However, I mentioned a possible database issue because the loading of the dashboard seemed to have slowed down after reducing the size of the DB instance.
Here are the screenshots that show the time it takes to load the dashboard:
It takes quite a while to load the "Network inventoried devices" widget, but there aren't any slow query at all:
Do you have any idea of what is causing all this delay in loading this specific widget and the dashboard as a whole?
cconard96
commented
4 months ago It looks like there is a bug that kept the data for the requests made to load the dashboard cards from being saved on the server side. So, none of the SQL requests are included in the debug bar. For the request timings, this is the entire request time including the time spent stalled. In debug mode, your session file isn't closed early so each request has to wait for the previous ones to finish in order to get a lock on the session file to be able to open it. You can see more detailed timing info in your browser's developer tools (F12 key > Network tab > Select a request > Timing sub-tab in Chrome).
For the missing data from the dashboard requests, I opened #17567 that seems to resolve the issue.
rafaelse
commented
4 months ago I'll wait for the next release to include the fix from issue https://github.com/glpi-project/glpi/pull/17567 so that we can get more information on which queries are slowing down the loading of some dashboard cards.
If this problem occurs to more people, then maybe some patch would be necessary. Otherwise, we'll see how we can optimize our database to improve the user experience.
trasher
commented
3 months ago Since the patch is quite small and has a quite low impact, you maybe can consider applying it right now; so you can report problematic queries as soon as possible.
MinusCortex
commented
1 month ago Hello everyone, i'm having the same issue as @rafaelse
we are running GLPI 10.0.16 behind an AWS Application loadbalancer (ALB) , with 2 ec2 instances and an EFS to store GLPI configuration the database is handled by a db.t4g.small RDS instances with mariadb 10.6.18.
dashboards cards are slow to load and some of the cards won't load at all, we discovered this issue when we started using the helpdesk dashboard who has a lot of issue while loading. one of the workaround was to remove some cards and keep only the strict necessary but it's not ideal.
some of them reach the maxium request time and throw a 504 error
Code of Conduct
Is there an existing issue for this?
Version
10.0.16
Bug description
Some graphs from the dashboard are very slow to load or often don't load at all. It mainly applies to that graph that shows the amount of tickets by status through the months, but similar symptoms are noticed on graphs on top of the ticket listing.
We are running our workloads on AWS EKS, and the database on a db.t4g.small instance in RDS. As can be seen on the image below, the load on the database is ok for most of its usage, except for the case mentioned above.
I wonder if there is any optimization that can be done to the database that will improve this scenario. Maybe adding some new indexes, or changing some MySQL parameters.
Even on a larger RDS instance, it takes a while to load some of the graphs.
Relevant log output
No response
Page URL
No response
Steps To reproduce
No response
Your GLPI setup information
Information about system installation and configuration
Server
Operating system: Linux production-7c77d8d784-85nrl 5.10.219-208.866.amzn2.x86_64 #1 SMP Tue Jun 18 14:00:06 UTC 2024 x86_64 PHP 8.3.9 fpm-fcgi (Core, PDO, Phar, Reflection, SPL, SimpleXML, Zend OPcache, bz2, cgi-fcgi, ctype, curl, date, dom, exif, fileinfo, filter, gd, hash, iconv, imap, intl, json, ldap, libxml, mbstring, mysqli, mysqlnd, openssl, pcre, pdo_sqlite, posix, random, readline, redis, session, soap, sodium, sqlite3, standard, tokenizer, xml, xmlreader, xmlrpc, xmlwriter, zip, zlib) Setup: max_execution_time="300" memory_limit="768M" post_max_size="20M" safe_mode="" session.save_handler="files" upload_max_filesize="20M" disable_functions="pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,exec,passthru,shell_exec,system,proc_open,popen,curl_multi_exec,parse_ini_file,show_source" Software: nginx Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36 Server Software: Source distribution Server Version: 8.0.36 Server SQL Mode: NO_ENGINE_SUBSTITUTION PHP version (8.3.9) is supported. Sessions configuration is OK. Allocated memory is sufficient. mysqli extension is installed. Following extensions are installed: dom, fileinfo, filter, libxml, json, simplexml, xmlreader, xmlwriter. curl extension is installed. gd extension is installed. intl extension is installed. zlib extension is installed. The constant SODIUM_CRYPTO_AEAD_XCHACHA20POLY1305_IETF_NPUBBYTES is present. Database engine version (8.0.36) is supported. No files from previous GLPI version detected. The log file has been created successfully. Write access to /var/lib/glpi/_cache has been validated. Write access to /var/lib/glpi/_cron has been validated. Write access to /var/lib/glpi has been validated. Write access to /var/lib/glpi/_dumps has been validated. Write access to /var/lib/glpi/_graphs has been validated. Write access to /var/lib/glpi/_lock has been validated. Write access to /var/lib/glpi/_pictures has been validated. Write access to /var/lib/glpi/_plugins has been validated. Write access to /var/lib/glpi/_rss has been validated. Write access to /var/lib/glpi/_sessions has been validated. Write access to /var/lib/glpi/_tmp has been validated. Write access to /var/lib/glpi/_uploads has been validated. Web server root directory configuration seems safe. Sessions configuration is secured. OS and PHP are relying on 64 bits integers. exif extension is installed. ldap extension is installed. openssl extension is installed. Following extensions are installed: bz2, Phar, zip. Zend OPcache extension is installed. Following extensions are installed: ctype, iconv, mbstring, sodium. Write access to /var/www/html/marketplace has been validated. Timezones seems loaded in database.GLPI constants
Libraries
SQL replicas
Plugins list
news Name: Alerts Version: 1.12.3 State: Enabled Install Method: Marketplace formcreator Name: Form Creator Version: 2.13.9 State: Enabled Install Method: Marketplace glpiinventory Name: GLPI Inventory Version: 1.3.5 State: Enabled Install Method: Marketplace itilcategorygroups Name: Grupos ItilCategory Version: 2.5.1 State: Not installed Install Method: Marketplace manufacturersimports Name: Importação de fornecedores Version: 3.0.8 State: Enabled Install Method: MarketplaceAnything else?
We ended up removing the slow graphs from the dashboards as to not affect the overall user experience with the system. Any improvement on this front would be most welcome.