General slowness in cards (responding, solution, etc.) when accessing the open ticket, only the first time GLPI 11 Rc5
Opened this issue · 19 comments
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
Do you see any network requests in the browser console during these times of slowness?
@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.
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).
@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
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.
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
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
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.twigtemplate 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.
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.twigtemplate 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)
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.
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.
I imagine it is not easy to improve this issue, since the version change is altering the architecture and other aspects, as you yourself mentioned. However, I would like to request that the internal team, if possible, pay more attention and care to this issue, so that the transition from version 10 to 11 is smooth and people do not perceive this lack of performance as a problem. Once again, I am comparing the performance of the same operations performed in version 10 and in the new version 11, and it still falls short of expectations. Unfortunately, this is not ideal or even remotely good for customer service, processes, and the like, which include ticket support or even other areas, if the problem extends to other modules of the system.
Everyone, I urge you all to check and pay special attention to this issue of slowness that still persists in versions 11.0.0 and 0.1.
I am sure that the performance fix will benefit everyone who is migrating to this new version, and we must remember that many use GLPI as a service center, so they spend most of their time on ticket-related operations.
Thank you in advance!
Taking advantage of this: I tried updating MariaDB to the latest stable LTS version and PHP to 8.4, but I didn't notice any changes in performance.
Guys, I ran another test using nginx instead of apache2, but there was no improvement either.
The results were the same as those shown previously.
There are already 2 PRs which attempt to improve performance although they may not directly resolve the issue you are seeing.
#21529 Reduces the amount of work related to the user info cards shown when hovering over a user in the timeline. They were all rendered, duplicated for every instance, on the server and all initialized on the client. Now they load on demand. It also moves some of the JS required for the timeline out of inline tags so they can be cached by the browser.
#21528 Reduces the amount of data added to the page which exposes GLPI configuration options in JavaScript. This affects initial page loading speed across the entire application.
Já existem 2 PRs que tentam melhorar o desempenho, embora eles possam não resolver diretamente o problema que você está vendo.
#21529 Reduz a quantidade de trabalho relacionada aos cartões de informações do usuário exibidos ao passar o mouse sobre um usuário na linha do tempo. Todos eles eram renderizados, duplicados para cada instância no servidor e todos inicializados no cliente. Agora, eles carregam sob demanda. Também remove parte do JS necessário para a linha do tempo das tags inline para que possam ser armazenados em cache pelo navegador.
#21528 Reduz a quantidade de dados adicionados à página, o que expõe as opções de configuração do GLPI em JavaScript. Isso afeta a velocidade de carregamento inicial da página em todo o aplicativo.
Cool, do you know if this improvement is planned for release in 11.0.2? I would like to test it when possible.
Cool, do you know if this improvement is planned for release in 11.0.2? I would like to test it when possible.
Nevermind. I am in the process of closing/undoing the changes.
Hello. I took the liberty of testing the procedures in version 11.0.2, and indeed, I couldn’t notice any significant improvements as mentioned might occur.
However, if there’s anything I can do to help us find a way to improve this — through tests, logs, or similar means — I’m at your disposal. Thank you for your attention, and I apologize in advance if I misunderstood something or missed any detail. I’ll be glad to help if you need any additional information.
glpi-11-0-2-performancetickets_QnV8TwpQ.mp4
By the way, if at any point I came across as rude to the team, I apologize. Since I sometimes use a translator, the message might not always come out exactly as intended.