[rt-devel] Re: RT SQL 'lockup' (mysql->99% cpu)

Iain Price iain.price at post.serco.com
Tue Jul 22 08:20:08 EDT 2003


> On 18.07.2003 12:15 Uhr, rt-devel-request at lists.fsck.com
> <rt-devel-request at lists.fsck.com> wrote:
>
> > create index user_MemberIdGroupId on
CachedGroupMembers(MemberId,GroupId);
> > create index user_PrincipalType on Principals(PrincipalType);
> >
> > However these two indexes together sped the query up to 12 seconds,
about
> > 770 times faster for me.
>
> Jesus, this really speeds things up.
>
> I had RT time out on me with 200 OPEN Tickets in a queue by just clicking
on
> the link to the Queue via "Quick Search" (i had set fcgi timeout to 300).
>
> Now, when i click, it displays the 200 open tickets in around 7 seconds.
> Could still be faster, but is much better as the previous timeout ;-)

Hehe glad its useful... Unfortunately no rest for me tho, my user base has
now taken to searching for 3 simultaneous requestors emails :(
Presumably if i could speed that search up (no chance) they'd then break it
with four, so i guess i'll have to find another approach such as bodging the
RT search page, or maybe remove some peoples limbs :P
Has anyone created a simple search page for RT that doesn't give users the
power to do stupid things, or has patched the existing page, save me digging
into that ?

Iain

PS: I think the issue is the users dont understand the search criteria dont
reset when you go back to the search page... maybe have two buttons,
'search' and 'refine search'? dunno, i can see this issue in two lights - a)
stupid user, who cares, rt does what it does, or b) users can completely
halt RT functionality which is a disaster - completely opposing views,
Jesse, which approach do you take for RT - user or admin tool?

PPS: Imagine if we gave our non IT-staff users access :P




More information about the Rt-devel mailing list