[rt-users] Is this slow? It seems slow.

[Val Luck]

Jamie,

Thanks so much for your message and comments.  I will definitely look into postgres and see if there are any indexes that could be added to speed things up.

With 3 people actively using RT, clicking on Resolve/Comment/Reply can now take up to 60 seconds for the screen to come up... which if people are on the phone with someone is a long time to have them sit there and wait. :-(

You mentioned that upgrading to RT version 3.0.3 (which is out now) could fix it?  Updating DBIx::SearchBuilder looks like a perl mod upgrade from CPAN, not RT?  Regardless, I'll look into it.

I can't believe that you have some db queries that are taking 20 minutes ..?!?  Wow.  Are you sure that's minutes and not seconds?  That would render RT useless.  :-(  I sure hope I don't see any degradation of that magnitude when I upgrade.

If you do add any more indexes for performance, it would be great if you could email me or the rt-users list.  I'll do the same.

Thanks again,

Val


-----Original Message-----
From: Jamie Wilkinson [mailto:jaq at spacepants.org]
Sent: Tuesday, June 10, 2003 6:34 PM
To: rt-users at lists.fsck.com
Subject: Re: [rt-users] Is this slow? It seems slow.


This one time, at band camp, Val Luck wrote:
>As it is right now with testing (creating tickets, re-assigning them, resolving them, etc) I can get up to a 5 to 15 second delay when going from "display" to "jumbo" mode.  

And similarly when clicking on Update from the front page, or
Resolve/Comment/Reply on the Display page.  Yes, this behaviour has been
seen in the past.  version 3.0.3pre2 of RT with a recent version of
DBIx::SearchBuilder (now 0.86) has fixed the speed problem for some people.
Unfortunately, I am not one of them.  My experience - 3.0.0 and 3.0.1 ran
dog slow, 3.0.1 with a 0.83_01 of DBIx::SearchBuilder ran faster, but page
loads were still taking about 30 seconds for the above operations, and now
with 3.0.3pre2 and DBIx::SearchBuilder 0.86 I am again experiencing 20
minute database queries.

>This seems kind of slow, doesn't it?  What will happen when 5 people are beating on it?  

postgres will fork a subprocess for each query, so that when 5 people are
doing things, you'll have 5 processes taking up about 20% CPU each.  And
when you hit the stop button, the subprocess won't stop.

>While clicking around in RT, it's common for the postgres db process 'postmaster' jump to 100% and sit there for the duration.  Additionally, I saw an earlier message posted about adding indexes to the RT database.  I had assumed that he was doing custom queries..?  Are their any extra indexes we could(should) add that are sanctioned by the RT programmers/DBAs that could speed things up?

I've added some indexes to a few tables, but in the mists of time and
experimentation, have forgotten which ones they are.

Turn on postgres logging (log_statements = true; syslog = 2 and so on) and
you'll see the large ACL query run for a while.  Copy that into psql and run
it yourself with "explain analyze" prepended, and you'll have some profiling
information you can use to work out the problem.

I'll be doing that mysel shortly, but it would be useful to have more than
one explain to help debug it.

-- 
jaq at spacepants.org                           http://spacepants.org/jaq.gpg
_______________________________________________
rt-users mailing list
rt-users at lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm