[rt-users] Performance Issues

[Kenneth Marshall]

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? 

The only problems that I have seen people posting concerned the display
of merged tickets -- see the archives for details. If you are not doing
that, could it be some sort of permissions problem or a problem with
local mods? We have many, many more tickets/users/transactions and the
display is pretty snappy. Also one comment, if you are in a pilot and
not production, now is the time to upgrade your DB to 8.3 which has
been out for a while and will support the full-text indexing that we
intend to implement here and update the wiki with the patch/process.

Ken