[rt-users] Performance Issues

[Ruslan Zakirov]

On Wed, Jun 18, 2008 at 10:01 PM,  <jmoseley at corp.xanadoo.com> wrote:
> David, what kind of disks are you using on your DB server?

Fast disks are major requirement for any DB, but such small DB can
live in the memory. As David has different servers for DB and
front-end then network latencies most probably have bigger impact on
performance.

> Generally speaking, mod_perl is slower than FastCGI - have you tried the latter?

This's not true! We have no any good RT benchmark results proving
either this or opposite.

> Next, have you tried any manual queries against your DB server to see if
> that's the source of the slowness?

Agree, any not tuned database will give you poor results.

>
> For reference, I just displayed a ticket with no attachments that has 100
> transactions and it displayed in 25 seconds.

In 3.8 we improved displaying history of tickets with many
transactions. People trying RT for a new setup are encouraged to try
RC1.

> James Moseley
>
> On Wed, Jun 18, 2008 at 10:13:40AM -0400, David Nalley wrote:
>> Hey guys,
>> I am running a pilot installation of RT and experiencing some
>> performance anomalies
>>
>> A bit about the environment:
>> RT 3.6.6 on CentOS 5, using mod_perl against Postgres 8.1. Postgres and
>> RT on separate boxes, and are on the same switch and subnet. Both boxes
>> have 1GB of RAM and Xeon 2.8Ghz processors. In addition all of the
>> clients in this pilot are also on the same subnet. The network is
>> switched 10/100.
>>
>> The problem
>> In most respects it's living up to it's expectations - however I am
>> noticing some significant lagging. Now keep in mind this is only a
>> pilot, I have a total of around 100 tickets, about 1800 transactions in
>> this system, and only 4 web interface users.  When I display one of the
>> tickets that has 35 transactions, it takes between 19 and 28 seconds.
>> That strikes me as a long time to load a single ticket, and is causing
>> some concern about what would happen if really loaded and under heavy
>> use.
>>
>> What I have done thus far:
>> I worked through the performance tuning section on the wiki - and showed
>> no improvement as a result. (In reality the database modifications had
>> already been  tweaked before RT showed up).
>> I have run pg_top against the database and it appears the queries are
>> being answered in a second or less.
>> In monitoring the box RT runs on, when I request some of the tickets
>> with more transactions, it grabs the CPU and keeps it occupied at 75-95%
>> utilization (showing up as system time not wait) for the duration of
>> loading the ticket with httpd being the process that grabs the CPU.
>> About 40% of available RAM isn't being used on the RT box at present -
>> so I don't think it's related to
>>
>>
>> Thus I seek the group's wisdom - are my expectations improper for length
>> of time to display a ticket? If not, where else should I be looking to
>> address performance?
>
>
>
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>
> Community help: http://wiki.bestpractical.com
> Commercial support: sales at bestpractical.com
>
>
> Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
> Buy a copy at http://rtbook.bestpractical.com
>



-- 
Best regards, Ruslan.