General slowness in cards (responding, solution, etc.) when accessing the open ticket, only the first time GLPI 11 Rc5

[lucaslevi-consultor-glpi]

Code of Conduct

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

Is there an existing issue for this?

• I have searched the existing issues

Version

GLPI 11 rc5

Bug description

Guys, I noticed this during service tests related to overall performance:

bug-lentidao-chamado-aberto-glpi-11_VmM8fEfC.mp4

As you may have noticed, when you click on “answer call” or “validate” for the first time, it causes this slowdown, but from then on, the speed returns to normal. If I refresh the page or have just entered the call, the first click on the card causes this slowdown.

Glpi 11 Rc5

Relevant log output

Page URL

No response

Steps To reproduce

No response

Your GLPI setup information

No response

Anything else?

No response

[cconard96]

Do you see any network requests in the browser console during these times of slowness?

[lucaslevi-consultor-glpi]

@cconard96 If I use Chrome's F12 console, I only see traffic when refreshing the page. After refreshing, when I click on the card, it does not generate new traffic.

[lucaslevi-consultor-glpi]

This performance issue seems similar to what happens in form management when you go to the create questions tab; it takes a long time to load the sections, etc. There were even discussions here about performance from the first alpha to this one (taking the opportunity to comment).

[lucaslevi-consultor-glpi]

@cconard96
Now that I've noticed it better, the slowness is on the call page itself, not exactly related only to the buttons. Look how it freezes when trying to scroll up and down the timeline and on the right side as well to load the information. When I perform the same operations in the current version 10 with the same number of follow-ups, validations, etc., it works normally.

This is concerning if the final version is released like this, mainly because when it comes to calls, perhaps not the requester, but the technicians spend most of their time in this view.

lentidao-dentro-do-chamado-glpi-11_4I1uVCIr.mp4

[lucaslevi-consultor-glpi]

Guys, with the release of the new version 11.0.0, I can confirm that the slowness and lack of performance/delay in loading remains the same when viewing within the call (same as in the video).

The test I will do is to update version 10 again to the latest version of 11 to see if there will be any different behavior.

[lucaslevi-consultor-glpi]

Guys, I ran a new test using glpi 10.0.19 and updating to the current version 11.0.0, and the slowness and crashes remain the same.

Note the comparison of speed and performance between versions 10 and 11.

In version 10, the speed of opening cards and loading information after pressing F5 is very smooth, but in version 11, simulating the same operation, it crashes, takes a long time to open the cards, and when typing text, it only appears seconds later, etc.

comparacao-glpi1opara11-responderchamados-velocidade-e-desempenho_pwvAoXsF.mp4

[lucaslevi-consultor-glpi]

After updating to the new version 11.0.1, unfortunately there still doesn't seem to be any improvement in this regard.

glpi-11-0-1-slow-ticket-interaction_gIae2ah8.mp4

[cconard96]

I spent some time this weekend analyzing the performance of the main ticket form tab (timeline view).

With debug mode disabled and env set to production, on a completely new ticket with just 3 words as the ticket name and content:

• The initial page content is 35.8kb compressed (205kb actual) and takes 300ms avg to get it from the server. This part isn't terrible given how GLPI is designed (not SPA). It should be noted though that almost 25% of that compressed size is CFG_GLPI data being dumped into JS. This isn't specific to the ticket timeline but still of note for overall performance.
• The content of the main ticket tab is 58.4kb compressed (390kb actual) and takes another 300ms avg. Most of the time taken here on the server is rendering the layout.html.twig template and included templates.
• 106 network requests are made (including ones that ended up using cached content)
• 95.3kb of compressed data is transferred with 28.3MB of total resources being loaded
• It takes a full 7 seconds for all network requests to stop

Now specifically talking about the ticket timeline tab content:

• It contains 129 inline scripts, and this can quickly increase as you add timeline items. In another ticket with 5 tasks, I saw 170 inline scripts.
  • The tooltips for user info card templates are rendered in duplicate for each instance (avatar, user link, etc). Maybe a limitation with SSR or at least how it is done currently.
  • 107 inline scripts utilize the $(function() {}) syntax to delay execution until the DOM is ready and/or to keep variables from being added to the global scope. This was noted in the past to cause client-side delays and should be able to be replaced with deferred scripts <script defer> or modules <script type="module">.
  • A lot of the script content could have been moved into actual JS files and simply called as needed to deduplicate the code and reduce the amount of inline scripts.
    • Date/time inputs for example, which there can be a lot of in this view, all dump an inline script with mostly the same code to initialize Flatpickr for the date/time input.
    • Select2 dropdowns are another culprit of near-duplicate inline scripts being added for every dropdown although this case may be harder to avoid.
• 4 instances of TinyMCE are all being initialized immediately despite no TinyMCE editors being visible. I think all of them are in the new followup/task/etc forms that get added to the page and hidden. TinyMCE is a noted source of performance issues especially when there are multiple editors. This does not increase with the number of actual items in the timeline since the item forms are loaded as-needed when you go to edit them.

[lucaslevi-consultor-glpi]

I spent some time this weekend analyzing the performance of the main ticket form tab (timeline view).

With debug mode disabled and env set to production, on a completely new ticket with just 3 words as the ticket name and content:

• The initial page content is 35.8kb compressed (205kb actual) and takes 300ms avg to get it from the server. This part isn't terrible given how GLPI is designed (not SPA). It should be noted though that almost 25% of that compressed size is CFG_GLPI data being dumped into JS. This isn't specific to the ticket timeline but still of note for overall performance.
• The content of the main ticket tab is 58.4kb compressed (390kb actual) and takes another 300ms avg. Most of the time taken here on the server is rendering the layout.html.twig template and included templates.
• 106 network requests are made (including ones that ended up using cached content)
• 95.3kb of compressed data is transferred with 28.3MB of total resources being loaded
• It takes a full 7 seconds for all network requests to stop

Now specifically talking about the ticket timeline tab content:

• It contains 129 inline scripts, and this can quickly increase as you add timeline items. In another ticket with 5 tasks, I saw 170 inline scripts.

  • The tooltips for user info card templates are rendered in duplicate for each instance (avatar, user link, etc). Maybe a limitation with SSR or at least how it is done currently.

  • 107 inline scripts utilize the $(function() {}) syntax to delay execution until the DOM is ready and/or to keep variables from being added to the global scope. This was noted in the past to cause client-side delays and should be able to be replaced with deferred scripts <script defer> or modules <script type="module">.

  • A lot of the script content could have been moved into actual JS files and simply called as needed to deduplicate the code and reduce the amount of inline scripts.

    • Date/time inputs for example, which there can be a lot of in this view, all dump an inline script with mostly the same code to initialize Flatpickr for the date/time input.
    • Select2 dropdowns are another culprit of near-duplicate inline scripts being added for every dropdown although this case may be harder to avoid.

• 4 instances of TinyMCE are all being initialized immediately despite no TinyMCE editors being visible. I think all of them are in the new followup/task/etc forms that get added to the page and hidden. TinyMCE is a noted source of performance issues especially when there are multiple editors. This does not increase with the number of actual items in the timeline since the item forms are loaded as-needed when you go to edit them.

Thank you for your response. I figured that the version change with the inclusion of new items and features would be the reason, and I understand that this can be improved. Speaking as a consultant, I see that for the new version 11 to be good for use in calls, more specifically speaking, apart from some bugs that are already being resolved, this issue is the only problem I see as preventing its use in production for several clients, as it greatly affects the technician's experience in customer service. By resolving this general slowness within the call, which may also be impacting other tabs, I believe that version 11 will finally become more achievable for various types of clients and scenarios.

I am emphasizing this because it greatly influences the quality of the system, and you yourselves know that many clients are prejudiced when they are unfamiliar with the system. Imagine someone doing a new installation of the system and encountering this issue? It will diminish credibility. My concern here, as with other issues I have already raised, is thinking exclusively about the overall context.

I leave here the appeal, if applicable, to look internally for a good strategy to improve this issue. I understand that this particular point, as I mentioned before, is still a concern, and solving it will certainly make the new version 11 a more desirable product.

Translated with DeepL.com (free version)

[cconard96]

Nothing I listed is likely a major source of issues on its own but rather one potential part of the overall slowness. Some apply to more than just the ticket view and some may not be easy to change given the current architecture.