[GLPI 11] Very slow first load of /front/ticket.php after Central page in GLPI 11 (not in 10.0.20)

[JeremieMercier]

Code of Conduct

• [x] I agree to follow this project's Code of Conduct

Is there an existing issue for this?

• [x] I have searched the existing issues

Version

11.0.1 and 11.0.2

Bug description

On GLPI 11.0.1 and 11.0.2 (Docker official image), the very first load of the ticket list /front/ticket.php right after visiting the Central page (/front/central.php) is very slow: about 11–13 seconds of backend time.

Key points:

• The issue happens only on the first /front/ticket.php after going through the Central page.
• If I wait for the Central page to fully finish loading and all background work to complete, then go to the ticket list, /front/ticket.php is fast.
• Once this first slow request is done, navigating between ticket pages or returning to /front/ticket.php with the same default search is fast.
• The slowness appears again only after I visit the Central page and quickly go back to the ticket list.

According to the Symfony profiler:

• The slow /front/ticket.php request shows ~11–13 seconds in SessionStart::execute.
• Total SQL time is only ~76 ms for 242 queries.
• A standalone session_start() using GLPI's GLPI_SESSION_DIR is extremely fast (~0.0002 s), so it does not look like a filesystem or session handler issue.

I have tested with:

• all plugins disabled,
• automatic actions disabled / moved to CLI,
• dashboards removed (Central, Assets, Assistance),
• GLPI_AJAX_DASHBOARD=0,

and the behavior is still the same.

On the same environment and database with GLPI 10.0.20, this problem does not occur with a similar dashboard configuration.

From my point of view, this looks like a performance regression in GLPI 11 around the initialization of the session/user/context when coming from the Central page before the first ticket list load.

Relevant log output

Page URL

No response

Steps To reproduce

1. Install GLPI 11.0.1 or 11.0.2 using the official Docker image (glpi/glpi:11.0.x), with a real dataset (many tickets), and configure it normally.
2. Log in and you arrive on the Central page (/front/central.php).
3. Immediately click on the Tickets menu to open /front/ticket.php (do not wait for the central page to fully finish loading).
4. Observe the backend duration of the /front/ticket.php request (using Symfony profiler or browser DevTools): it takes about 11–13 seconds.

5. Then go back to the Central page again.

• This time, wait until the central page has fully finished loading (no more XHR / background requests in the browser network tab).
• Click on Tickets again.

6. Now the /front/ticket.php request is fast (normal response time).

7. Repeat the scenario and observe that the slow behavior only appears when navigating to the ticket list while the Central page is still doing background work.

Your GLPI setup information

No response

Anything else?

No response

[cconard96]

Are there any slow network requests on the Central page? A lot of background requests in GLPI may not close the session immediately so the session file is locked until the request completes. This causes requests to wait for previous ones to finish even if they are asynchronous.

[JeremieMercier]

Are there any slow network requests on the Central page? A lot of background requests in GLPI may not close the session immediately so the session file is locked until the request completes. This causes requests to wait for previous ones to finish even if they are asynchronous.

Hi @cconard96, yes, I’ve done some more tests and I can confirm there are slow background requests on the Central page, and they are linked to the Planning.

On the Central page, the slow background requests I see are mainly :

• common.tabs.php?_glpi_tab=Central$0&_target=central.php (XHR, html) => about 8621 ms
• planning.php?action=get_events&view_name=... (XHR, json, triggered by fullcalendar.js) => about 13389 ms
• planning.php (XHR POST) => about 14173 ms

I went to the Planning page and noticed that I had several plannings checked/visible (my own planning + other users).

Then I tried :

1. On the Planning page, I unchecked all plannings and left only my own planning visible.
2. I went back to the Central page and repeated the test:
   • Login => Central => immediately click on Tickets.

Result:

• The planning.php?action=get_events... XHRs on the Central page are now much faster.
• /front/ticket.php no longer shows the 11–13 seconds delay.
• The slowness completely disappears in this scenario.

If I re-enable multiple plannings (several calendars checked/visible), then:

• planning.php?action=get_events... on Central becomes slow again (up to 13–14 seconds),
• and the first /front/ticket.php after Central is again very slow.

On the same data and with the same number of plannings visible in GLPI 10.0.20, I do not have this problem.

[lucaslevi-consultor-glpi]

Hi @JeremieMercier , can you also check the performance within the ticket? What you mentioned about it being slow the first time seems very similar to what I’m experiencing in this issue #21115 — in the ticket handling area, but there it’s not just the first time; every time I hit F5, the slowdown is the same.

[JeremieMercier]

Hi @JeremieMercier , can you also check the performance within the ticket? What you mentioned about it being slow the first time seems very similar to what I’m experiencing in this issue #21115 — in the ticket handling area, but there it’s not just the first time; every time I hit F5, the slowdown is the same.

Hi @lucaslevi-consultor-glpi,

I’ve just done a few more checks.

In my case, I do not see the same behavior as in #21115 on the ticket handling page itself :

• Opening a single ticket is normal.
• Pressing F5 on the ticket page is also fast on my test instance.
• I don’t have a persistent slowdown every time I reload a ticket.

The slowdown I reported happens in a very specific scenario :

1. Go to the Central page.
2. While the Central page is still doing background work
3. Immediately go to the ticket list (/front/ticket.php).

Only the first /front/ticket.php after Central is slow (it waits for the slow planning.php calls).
Once that first request is done:

• the ticket list is fast,
• refreshing the list or a ticket with F5 is fast as well,
• until I go back to Central with multiple plannings checked.

So it looks like my issue is more about Planning + Central + ticket list interaction (session lock while loading planning events), whereas your issue in #21115 is about slowness directly in the ticket handling area on every reload.

I dont reproduce the behavior you describe inside the ticket itself on my side.

[lucaslevi-consultor-glpi]

@JeremieMercier Yes, unfortunately I've been having this problem since the alpha version, which is why that issue has been open for a while. According to comments from my teammate, some changes have been made that are affecting the overall performance of the system.

Out of curiosity, which browser do you use to access GLPI? And what is the configuration of your GLPI Linux server? Apache, memory, CPU, etc.

[JeremieMercier]

@JeremieMercier Yes, unfortunately I've been having this problem since the alpha version, which is why that issue has been open for a while. According to comments from my teammate, some changes have been made that are affecting the overall performance of the system.

Out of curiosity, which browser do you use to access GLPI? And what is the configuration of your GLPI Linux server? Apache, memory, CPU, etc.

Our server is a cloud VPS running Debian 12 with 6 CPUs (I don't have the CPU model) 18 GB RAM, and we run GLPI 10.0.20 in production with an unofficial docker image that uses Apache as the web server, and soon when the small problems of GLPI 11 are resolved, we will migrate to GLPI 11 with the official docker image which also uses Apache if I am not mistaken.

[JeremieMercier]

Hi @cconard96,

Yes, I can confirm, when the "Events done" box is checked, I have the slowness problem :

When the box is unchecked, even with multiple planning visible, I don't have the slowness problem.

But we agree that this is still a performance issue, right ? Because when I say multiple planning visible, I mean a group of 3 technicians plus my own planning only. That's not normal, is it ?

[cconard96]

But we agree that this is still a performance issue, right ? Because when I say multiple planning visible, I mean a group of 3 technicians plus my own planning only. That's not normal, is it ?

I would say that no, it is not normal. I am also looking at the query the widget on the homepage uses and it is asking the server for every event +/- 5 years from the current date but this seems to have been that way since GLPI 9.5.

[JeremieMercier]

On our production database running GLPI 10.0.20, I don't have the "Event done" checkbox like I do in GLPI 11.0.2.

[cconard96]

So that is probably why you see the issue only now with GLPI 11; I imagine there are quite a lot of finished events. IMO the homepage widget should probably override this filter but I don't know the best way to handle it since filters are read from the session data.

[JeremieMercier]

In that case, wouldn’t it be useful to disable this checkbox ? In my case, I don’t see any use for it ;), but I don’t doubt that it’s useful for others Or could you make it so that this box isn’t checked by default ?

[JeremieMercier]

Hello @cconard96, do you have any news ?

[OteJlo]

Hello, the performance issue is still present in GLPI version 11.0.4, thanks.

[WEBudoGT]

I'm having the same issue. Each page loads so slow. I'm running on docker and all I see is php using 100% cpu on a single core.

Not sure if this is related, but I even installed on another server with more capacity and it behaves the same.

[lucaslevi-consultor-glpi]

Hi @WEBudoGT , can you also check the performance within the ticket? What you mentioned about it being slow the first time seems very similar to what I’m experiencing in this issue #21115 — in the ticket handling area, but there it’s not just the first time; every time I hit F5, the slowdown is the same.

[WEBudoGT]

Hello @lucaslevi-consultor-glpi

It seems to be another problem, because it happens no matter which link on the menu I click. Every page load is slow. The whole window is blank for several seconds, then it renders everything.

[cconard96]

Hello @lucaslevi-consultor-glpi

It seems to be another problem, because it happens no matter which link on the menu I click. Every page load is slow. The whole window is blank for several seconds, then it renders everything.

If the performance issue is not specific to the Central/planning page or the ticket timeline, please open a new bug report. It would be helpful to have the metrics from GLPI's debug bar including the server and client performance metrics, any slow queries, and the info under the HTTP Requests tab > Profiler.

[WEBudoGT]

Thanks for the suggestion @cconard96 I just want to debug and discard that I'm not doing something wrong. Maybe just installing on a plain linux machine instead of using docker. Once I have it a bit clearer, I'll proceed ;)

[PPCM]

Hello Guys, I expirent the same issue, after an upgrade from GLPI 10 to GLPI 11, The application has become unusable. The docker version is used (I don't know if it matter)

For the tickets list, here the debug for stats on the top of the page

and debug in the bottom

If I click on a ticket link, I have to wait more than 3 minutes for the page to start loading, after

What I've noticed is that as long as the tickets page isn't fully loaded, it's difficult to load another GLPI page. But when the tickets page is fully loaded, the loading of other pages is instantaneous, including the tickets page To validate that, I goes to users page, then for a user, I open his tickets

Hope it can help

Thanks guys

[lucaslevi-consultor-glpi]

@PPCM Do you also notice slowness when entering the ticket? Like it gets slow, the response card buttons freeze a little, and then it goes back to normal speed? From what I can see, this slowness affects both inside and outside the ticket, based on what I've already observed and reported in another issue and what I see others commenting on.

[PPCM]

@lucaslevi-consultor-glpi I can confirm that clicking on a ticket is extremely slow. In some cases, the server stops responding altogether.

I ran an experiment: I removed all the statistics from the tickets list page, and it became completely smooth again, even for the tickets themselves.

So, after adding the statistics elements back, I continued experimenting by adding some indexes to the GLPI tables for a few statistics items, and that significantly improved things. Perhaps the solution lies in improving the database structure.

We have the same slowness issue on all pages displaying statistics.

In the meantime, I removed the statistics again so I could work on it.

[lucaslevi-consultor-glpi]

@PPCM Can you tell me what statistics you are referring to? And what would be the permission in the profile? It seems like an interesting temporary solution.

[PPCM]

this one

[lucaslevi-consultor-glpi]

Este

I figured that's what they were, I didn't notice any significant difference in my case, but I'll take your suggestion for now. It's a shame about the slowness, I even have an open issue since the alpha version that I believe is part of this slowness, I hope they do something good to fix it, especially now that people are migrating to 11, although it's not a bug, it compromises the experience.

[PPCM]

@lucaslevi-consultor-glpi I take back what I said; the ticket page is slow too. I must have gotten lucky the other day.

However, I can confirm that there's a real improvement in the tickets list when statistics are removed.

[lucaslevi-consultor-glpi]

Understood. I have a question for the team: now that there are more reports of performance issues, can something be done to ensure that GLPI 11 performs at least as well as version 10, so that we have a better experience?

Thank you for your continued attention!