[rt-users] RT tuning problems

Jason A. Diegmueller doogles at doogles.com
Thu Jan 6 11:37:07 EST 2005


Tomas--

I have found RT 3.2.3rc1 (not just RT 3.2.2) specifically, when combined with 
DBIx::SearchBuilder 1.15 or greater, increased performance with our "trouble 
tickets" 300%+.

RT 3.4.0rc1 showed 20% gains on top of the above figures.

I posted a few weeks ago with exact figures.

Additionally, in my testing, I found negligable difference btween FastCGI and 
mod_perl.  In our environment, I run Apache 1.3.33 with mod_perl 1.29.

-jd

On Thu, 6 Jan 2005, Tomas A. P. Olaj wrote:

> On the marvelous Wed, 5 Jan 2005, Todd Chapman wrote kindly to me ...
>
>> I would try RT3.2.3rc1 and make sure that you have the latest
>> DBIx::SearchBuilder. Don't forget to restart Apache...
>>
>> -Todd
>
> Thanks, all You people for helping!
>
> We run RT3.2.1 (not sure if RT3.2.2 has better performance) and
> DBIx::SearchBuilder 1.16, and still have problems with long history
> tickets.
>
> As for now, we greatly appreciate all responces and help, and our
> conclusion from the latest responses is that the problem is RT itself
> (the latest stable release)?
>
> Is it faster to run FastCGI or modperl? We are currently testing to find
> the optimal Apache dist to run.
>
> cheers,
> Tomas
>
>> On Wed, Jan 05, 2005 at 09:46:08AM +0100, Tomas A. P. Olaj wrote:
>>>
>>> This is written by our web-admin and Postgres DBA, Rafael Martinez, which
>>> is not a member of this list, and forwarded to me:
>>>
>>> -->
>>>
>>> We are having performance problems in our RT (3.2.1) installation.
>>>
>>> Description:
>>>
>>> - If we try to display a ticket with a long history, it takes many
>>> seconds before the webside is generated. (Ticket/Display.html?id=<ID>).
>>> In some browsers (f.ex.IExplorer) the webside is not show until the
>>> browser gets all the data.
>>>
>>> - The server is not busy and has plenty of idle resources.
>>>
>>> - We do not have problems with the database. It is not busy at all. Not
>>> IO problems either.
>>>
>>> - apache uses 100% of cpu when Ticket/Display.html?id=<ID> is executed.
>>> If we run strace, can we see a lot of "time(NULL)=xxxxxxxx" system
>>> calls, in our case, around 86000. 177 sql queries are send to the
>>> database and it takes 20 seconds between the first and the last sql
>>> query are send to the database.
>>>
>>> - It looks like apache is in some idle/loop stage (time(NULL)=xxxxxxxx)
>>> between sending and receiving data to/from the database.
>>>
>>> Our system:
>>> - Red Hat Enterprise Linux WS release 3 (Taroon Update 4).
>>> - kernel 2.4.21-20.ELsmp
>>> - 4GB Ram
>>> - 2 x Intel(R) Xeon(TM) CPU 2.40GHz.
>>> - 2 x scsi 36GB 15K (raid 1)
>>>
>>> - We are running the webserver and the database in the same server.
>>> - Database: PostgreSQL 7.3.5
>>> - Webserver: apache RH version: httpd-2.0.46-44.ent with
>>> mod_perl_1.99_12
>>>
>>> Anyone with the same problem?
>>>
>>> --
>>>  Rafael Martinez, <r.m.guerrero at usit.uio.no>
>>>  Center for Information Technology Services
>>>  University of Oslo, Norway
>>>
>>> The problem is that our customer complains about the time it takes to load
>>> a long ticket history, and this is a "show-stopper" for us. The latest
>>> version of DBIx::SearchBuilder is also installed.
>>>
>>> --
>>> ________________________________________________________________________
>>> Tomas A. P. Olaj, email: tomas.olaj at usit.uio.no, web: folk.uio.no/tomaso
>>>  University of Oslo / USIT (Center for Information Technology Services)
>>>    System- and Application Management / Applications Management Group
>>> _______________________________________________
>>> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>>>
>>> Be sure to check out the RT wiki at http://wiki.bestpractical.com
>
> -- 
> ________________________________________________________________________
> Tomas A. P. Olaj, email: tomas.olaj at usit.uio.no, web: folk.uio.no/tomaso
> University of Oslo / USIT (Center for Information Technology Services)
>   System- and Application Management / Applications Management Group
>



More information about the rt-users mailing list