RT performance or feature request

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?

Thanks for any hint.

  • Wang

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

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 :frowning: 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.

Thanks for any hint.

  • Wang

http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

We’re hiring! Come hack Perl for Best Practical: http://bestpractical.com/about/jobs.html

Best regards, Ruslan.

Schultz, Eric wrote:

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.)

Jesse

Jesse Vincent wrote:

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.

Thanks for the great tool.

  • Wang

Jesse Vincent wrote:

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.

Thanks.

  • Wang

Jeff Voskamp wrote:

Jesse Vincent wrote:

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.

Jeff

MaxChild (1.5 KB)