Ticket object Tree Select hangs zammad 5 and page become not responsive

  • Used Zammad version: Zammad 5.0.x
  • Used Zammad installation type: yum
  • Operating system: CentOS 8
  • 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:
    → ItemB1
    → ItemC1

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.

Hope for your help

What on earth are you doing with an 5000 item object tree?

Sorry I have nothing of value to add. Just wondering.

Not 5000 items of Tree select, but One Object Tree Select with 5000 items inside.

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?

Any suggestions what to do?

I guess one approach would be to split the main tree into logical subtrees and use the new core workflow system to show and hide the subtrees.

It is not a technical solution but at least a practical attempt to solve your issue :wink:

BR wucherpfennig

hello, thank you for reply, I tried it, but honestly it seems to become little bit faster but zammad 5 still running very slow.

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.

See our requirements:

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?


nothing beside Core Workflows which imho has a big impact UI wise

If you believe this is a missing functionality in Zammad, please create a feature request:

Thank you @MrGeneration !

Sorry for taking your time, but what about optimization features for Zammad? It is also for Feature request?


Additional note:

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.

Yes. Improving existing functions is also counting as a feature request.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.