I have two iTop installations on the same server with the same setup and data but in two different iTop versions 2.6.0-4294 and 2.6.1-4463. Both installs have about 500 organizations in the database, each of them has one of two Parent organzations defined. iTop v. 2.6.0 works fine. Version 2.6.1 however has a problem with performance when organizations are being loaded. For example in User Preferences > Favorite Organizations > All
or in Search for Person Objects > Organization > (Magnifying glass) > All
Seems like a duplicate of [#1747], do you confirm ?
Related
Tickets:
#1747It might be related to [#1747], but I am not sure it is a duplicate, because we do not experience the issues with any other objects besides organizations, and the problem occurs in firefox and IE.
Related
Tickets:
#1747The 1747 bug is triggered when :
All browsers are concerned, and impact in IE is certainly the worst (old JS engine).
Can you try to apply the fix ? See https://github.com/Combodo/iTop/commit/3c4fe338b61b5de67e9edf070e5b02a79f4c0eba
Hi Pierre,
thank you for the fix. It works, but the performance is still somewhat 4 times worse than it used to be in v. 2.6.0
Here are the load times I measured:
With 511 organizations in the DB and the user Preference setting of "Default length for lists" set to 600, the full load auf the "Preferences..." lasts:
v2.6.1 without fix | never (> 5min) ---| never (> 5min)-- | 1min, 45sec
v2.6.1 with fix -----| 3 sec -------------- | 8 sec -------------| 3sec
v2.6.0 -------------- |<1 sec -------------- | 2 sec -------------| <1 sec
Last edit: Switchfoot 2019-10-29
Thanks for this feedback !
Can you try to see where is this time consumed using your browser dev tools ? To identify if it is server side or client side ? In Firefox, that would be in the network tab.
When performing multiple tests using firefox dev tools I get similar reload times for the same preference page in v2.6.0 (0.94-4.30 sec) and fixed v2.6.1 (2,15-4,93sec). So I think my previous timed realoads were just an imprecise coincidence and the ticket can be closed as a duplicate of the already fixed #1747.
Thank you very much for your help!
Thanks, closing this