Browser + version: all browsers, on firefox it seems to me it works faster
Expected behavior:
zammad 5 working fast, no lags, while loading tickets
Actual behavior:
I have an Object Tree Select with about 5 000 items in 4 levels in depth (in database postgresql it is about 54 000 lines due to its syntaxis). When I login to Zammad 5 it is fast if no ticket on left side bar (tab) is opened. But if these is any tickets on left side tab then it takes much time to load them and more tabs are open then more time it takes to load them.
Overviews are loaded fine and fast even if data of this filed (tree select) exists in overview. When you click to any ticket to open it then it takes about 1-2 minutes to load the page and do update. If these is more than 10 tickets on left side bar (tab) then it can take more than 20 minutes to load a page.
Finally I disabled this Object in postgresql with update active column for this object to 'f' in table object_manager_attributes, then Zammad 5 started to work fast. No lags.
I described it in previous my ticket (https://community.zammad.org/t/after-updating-to-zammad-5-it-started-working-much-slower/8320) but I closed it because I found the reason why it works slow. For now I need help how to optimize this Object and make it work faster?
Is there any way to make it work faster? Because we need this Object for Tickets.
I tried to divide each levels of Tree Select to separate Objects, but 4th level has about 5 000 items. and I faced a problem that it become impossible to use autocomplete this field in object SELECT and tree select object with only 1 level is also working slow.
Steps to reproduce the behavior:
install Zammad 5 on CentOS 5, then create an Object Tree Select with about 5000 items with 4 level in depth. So that you will have structure of Tree Select object like follows:
ItemA1
→ ItemB1
→ ItemC1
->ItemD1
and here ItemD1 is about 5000 items in count, ItemA1 is about 15-20 items. ItemB1 and ItemC1 are about 20-100 items.
Then login to Zammad 5 and open tickets try to work.
In Zammad 4, it seems to me it was working faster then in Zammad 5.
Could it be so that something was changed on Tree Select object for Zammad 5, because on Zammad 4 it works faster than on Zammad 5 with the same amount of items in TreeSelect Object?
Ironically this isn’t directly an Zammad issue perse but a Browser issue.
The way Zamamd works makes your browser have the whole HTML context of each ticket life in your browser. Browser’s don’t like it too much if this gets a lot at some point.
You mentioned that you reduced the object size but the UI still feels slow.
This may be due to you having open very very large tickets.
So what you’ll probably be able to see within your task manager is your browser going berserk when trying to work on Zammad.
What we’ve seen / learned in the past is that Firefox is the most robust browser when it comes to ridiculous amounts of HTML code (I’m not judging here).
However, what also may come into account is your browser using the ajax fallback instead of the preferred websocket method. You can enable the fallback mode to see if it gets slightly better.
Thank you for reply, I tried to switch for using ajax, but it is not solved the problem at all. I think as we create a ticket object, then this object is loaded every time for every ticket you open. Am I right?
Is there any way to create some api which could load only peace of data which user has requested or load a ticket object only once (not for every ticket) when used is logging in and then somehow assign selected item to ticket?
It seems to me that Zammad 4 performance in term of this problem is faster than on Zammad 5, is there any changes on ticket object processing?
I tried to use Tags and they are searchable, and does not have impact on system performance if you have many items to search, I think it is because it is not a ticket object.
