RT Slow to add and remove group members

RT Users
1

Our production RT instance (3.6.3 - old, I know) takes a really,
really long time to add and remove group members.

Our database is MySQL and the CachedGroupMembers table has the index:
KEY CachedGroupMembers3 (MemberId,ImmediateParentId)

What can we do to improve the situation (yes, I would be upgrading if
that were possible at the moment)?

Would running shrink_cgm_table.pl be a good idea?

Thanks!

-Todd

2

Our production RT instance (3.6.3 - old, I know) takes a really,
really long time to add and remove group members.

Our database is MySQL and the CachedGroupMembers table has the index:
KEY CachedGroupMembers3 (MemberId,ImmediateParentId)

I recall that index on Via is relevant for the shredder, so may be
it’s also relevant for removing a member as it also means dropping
records. Without full SQL log it’s hard to say. It’s better to write a
script that adds a user to a group and deletes him right after. Use
this script to collect all queries with hi-res timings. All queries
required to see queries that are executed many times even if those are
quite fast.

What can we do to improve the situation (yes, I would be upgrading if
that were possible at the moment)?

Would running shrink_cgm_table.pl be a good idea?

Shrinking would make lookups faster. Let’s say 30% faster as table
gets ~30% smaller. As far as I know there is no harm in running it on
3.6.x.

Thanks!

-Todd

Best regards, Ruslan.

3

Ruslan,

Thanks for the feedback. The group happens to be an AdminCc on many
queues with lots of members. Do you think that matters?On Mon, Dec 13, 2010 at 8:39 PM, Ruslan Zakirov ruz@bestpractical.com wrote:

On Tue, Dec 14, 2010 at 12:27 AM, Todd Chapman todd@chaka.net wrote:

Our production RT instance (3.6.3 - old, I know) takes a really,
really long time to add and remove group members.

Our database is MySQL and the CachedGroupMembers table has the index:
KEY CachedGroupMembers3 (MemberId,ImmediateParentId)

I recall that index on Via is relevant for the shredder, so may be
it’s also relevant for removing a member as it also means dropping
records. Without full SQL log it’s hard to say. It’s better to write a
script that adds a user to a group and deletes him right after. Use
this script to collect all queries with hi-res timings. All queries
required to see queries that are executed many times even if those are
quite fast.

What can we do to improve the situation (yes, I would be upgrading if
that were possible at the moment)?

Would running shrink_cgm_table.pl be a good idea?

Shrinking would make lookups faster. Let’s say 30% faster as table
gets ~30% smaller. As far as I know there is no harm in running it on
3.6.x.

Thanks!

-Todd

–
Best regards, Ruslan.

4

Ruslan,

Thanks for the feedback. The group happens to be an AdminCc on many
queues with lots of members. Do you think that matters?

No idea. Never benchmarked that code. Especially when there are a lot
of members in one group.> On Mon, Dec 13, 2010 at 8:39 PM, Ruslan Zakirov ruz@bestpractical.com wrote:

On Tue, Dec 14, 2010 at 12:27 AM, Todd Chapman todd@chaka.net wrote:

Our production RT instance (3.6.3 - old, I know) takes a really,
really long time to add and remove group members.

Our database is MySQL and the CachedGroupMembers table has the index:
KEY CachedGroupMembers3 (MemberId,ImmediateParentId)

I recall that index on Via is relevant for the shredder, so may be
it’s also relevant for removing a member as it also means dropping
records. Without full SQL log it’s hard to say. It’s better to write a
script that adds a user to a group and deletes him right after. Use
this script to collect all queries with hi-res timings. All queries
required to see queries that are executed many times even if those are
quite fast.

What can we do to improve the situation (yes, I would be upgrading if
that were possible at the moment)?

Would running shrink_cgm_table.pl be a good idea?

Shrinking would make lookups faster. Let’s say 30% faster as table
gets ~30% smaller. As far as I know there is no harm in running it on
3.6.x.

Thanks!

-Todd

–
Best regards, Ruslan.

Best regards, Ruslan.