[rt-users] Re: Performance issues with RT3 (all versions)

[Jon Masters]

Nate Duehr wrote:

> Hmm... I just started out with some "basics"

This is why I always feel compelled to write extremely verbose initial 
messages on these lists - I have to instantly demonstrate to you that as 
someone who spends most of the day hacking on embedded boxes and does 
occasional sysadmin we can just get right down to the point :-).

> haven't run into MySQL being the culprit

In my experience on small scale systems MySQL is ressonable.

> Just a side-thought -- have you investigated network overload issues or 
> bottlenecks in the network getting to/from the RT machine

There are no problems.

> during the timeframe people are complaining?

Continuously.

> How many users do you typically have hitting it simultaneously?

One or two users. This is what I would call a small installation which 
should not push RT at all but performance is dreadful.

jcm>>Loading times over 5-10 seconds are out of whack in any case.

> Loading times of what -- the queue list

That takes at least 5-10 seconds but perhaps much longer.

> a ticket

That takes perhaps even a minute.

> Also how often are "idling" clients reloading the main page?

Usually one person uses RT and rarely will someone else in the building 
have a ticket to look at or be covering if our support guy is away.

>>There is only one process running most of the time and that is whatever
>>is running the perl - be it apache modperl or whatever.

> I usually only see apache itself jump to the top of a quickly-updating (1 
> second refresh) top screen

That is my point.

> rarely do I see MySQL pop up there long enough to matter

Which of course means nothing since it could be blocking on IO and 
apache might just be sitting in a tight pointless loop.

> and I never see anything named "perl"

However you will not because you are using mod_perl as am I.

> Let's see... what else... um, this is RT 3.0.11 from Debian... can't remember 
> if you said which version you were on.

Pretty much every release in the 3.x series from bestpractical.com.

> For the more typical "show 50 tickets" the query was over and the data 
> displayed in less than 3 seconds.

That would be fine.

> Pulling up one of those tickets with a 43.5 K file attachment was also too 
> fast to measure realistically.

That would be fine.

Jon.