Hi there,
Now RT will list all children of a ticket including non-direct children.
I have a ticket containing a very deep hierarchy tree, around 5,000
tickets, but with only 50 direct children. Disastrously, it takes RT
around 20 minutes to opening the ticket.
When I dived into this problem, I found that the time was spent on
querying mysql database, around 15 minutes.
Do you have any idea on improving the performance of mysql.
My box: 4G mem, dual Intel 2.8 G.
If we can’t improve the performance of mysql, is it possible to list
only the direct children?
I have a ticket containing a very deep hierarchy tree, around 5,000
tickets, but with only 50 direct children. Disastrously, it takes RT
around 20 minutes to opening the ticket.
When I dived into this problem, I found that the time was spent on
querying mysql database, around 15 minutes.
Do you have any idea on improving the performance of mysql.
My box: 4G mem, dual Intel 2.8 G.
If we can’t improve the performance of mysql, is it possible to list
only the direct children?
Thanks for any hint.
Wang
Why do you have such a deep/large heirarchy for one ticket? You really
shouldn’t do this in the future, I don’t think there is anything you can
do in the backend to speed things up.
Hi there,
Now RT will list all children of a ticket including non-direct children.
I have a ticket containing a very deep hierarchy tree, around 5,000
tickets, but with only 50 direct children. Disastrously, it takes RT
around 20 minutes to opening the ticket.
Heh Most probably want to turn on logging in your DB.
Start from mysql slow queries log.
When I dived into this problem, I found that the time was spent on
querying mysql database, around 15 minutes.
Do you have any idea on improving the performance of mysql.
You can grab list of the queries RT runs to show you that ticket and
check if all the queries use indexes.
My box: 4G mem, dual Intel 2.8 G.
If we can’t improve the performance of mysql, is it possible to list
only the direct children?
Yep. You can hack RT a little.
I have a ticket containing a very deep hierarchy tree, around 5,000
tickets, but with only 50 direct children. Disastrously, it takes RT
around 20 minutes to opening the ticket.
When I dived into this problem, I found that the time was spent on
querying mysql database, around 15 minutes.
Do you have any idea on improving the performance of mysql.
My box: 4G mem, dual Intel 2.8 G.
If we can’t improve the performance of mysql, is it possible to list
only the direct children?
Thanks for any hint.
Wang
Why do you have such a deep/large heirarchy for one ticket? You really
shouldn’t do this in the future, I don’t think there is anything you can
do in the backend to speed things up.
Eric Schultz
United Online
This tree was migrated from Bugzilla. Typically, we have hundreds of
tickets under a tree.
Because of the simplicity of Bugzilla, it can handle such an extreme
without difficulty.
This tree was migrated from Bugzilla. Typically, we have hundreds of
tickets under a tree.
Because of the simplicity of Bugzilla, it can handle such an extreme
without difficulty.
I think we’re autolimiting to a depth of “8 levels”. I’d be thrilled to
take a patch for 3.6 to make that configurable, so you could set it to
one. (I also bet that we could recast it to be a ticket search, not a
relationship search with ticket lookups for each item.)
This tree was migrated from Bugzilla. Typically, we have hundreds of
tickets under a tree.
Because of the simplicity of Bugzilla, it can handle such an extreme
without difficulty.
I think we’re autolimiting to a depth of “8 levels”. I’d be thrilled to
take a patch for 3.6 to make that configurable, so you could set it to
one. (I also bet that we could recast it to be a ticket search, not a
relationship search with ticket lookups for each item.)
Jesse
This will be a very useful extend for some customers.
This tree was migrated from Bugzilla. Typically, we have hundreds of
tickets under a tree.
Because of the simplicity of Bugzilla, it can handle such an extreme
without difficulty.
I think we’re autolimiting to a depth of “8 levels”. I’d be thrilled to
take a patch for 3.6 to make that configurable, so you could set it to
one. (I also bet that we could recast it to be a ticket search, not a
relationship search with ticket lookups for each item.)
Jesse
Jesse,
It might be a good idea to add a link “Expand the hierarchy” if the
hierarchy is not completely displayed.
This tree was migrated from Bugzilla. Typically, we have hundreds
of tickets under a tree.
Because of the simplicity of Bugzilla, it can handle such an extreme
without difficulty.
I think we’re autolimiting to a depth of “8 levels”. I’d be thrilled to
take a patch for 3.6 to make that configurable, so you could set it to
one. (I also bet that we could recast it to be a ticket search, not a
relationship search with ticket lookups for each item.)
Jesse
This is for 3.5-TESTING. You may have to do it -R since I’m forever
getting that backwards.
Feel free to tweak to apply locally, but at least you get the idea.
Most probably want to turn on logging in your DB.