[rt-users] Re: Performance Issues (a bug?)

Rich West Rich.West at wesmo.com
Tue Oct 12 11:51:30 EDT 2004


FastCgi has some nifty features and some ways to tweak performance.  
Believe me, you will find a HUGE improvement if your FastCgiServer line 
looks something like the following (specifically, the "-processes" 
argument):
FastCgiServer /your_path_to_your_rt_install/bin/mason_handler.fcgi 
-idle-timeout 120 -processes 5

A dual 600Mhz box isn't the greatest, but, for RT and only RT (plus the 
webserver and mysql server), that should be fine.

If, when using the above option to FastCGI, you don't get better 
performance, it's time to start looking elsewhere (eg: on the database 
side).

-Rich

>On Wed, Sep 08, 2004 at 03:55:00PM -0400, Dan Pritts wrote:
>  
>
>>I've got a brand-new installation of RT 3.2.1 running on Fedora
>>Core 1, with apache 2 & FastCGI, with a mysql backend.  We have
>>fewer than 100 tickets in our database.  In general all the tools
>>are those from Fedora - I think I had to build FastCGI by hand.
>>
>>The hardware is a dual-CPU pentium iii 600MHz.  SCSI disks and 1 gig
>>of RAM.  Nothing else is happening on this box.
>>
>>things were horribly slow with only one mason_handler.fcgi process.
>>(it would take 5-10 seconds to display a ticket - generally most of the
>>    
>>
>
>This is exactly the same as I reported 1-2 weeks ago, I run RT3.2 and
>RT3 on Debian on two different machines (Celeron class w/ 768MB RAM,
>idle and I normally know how to setup a server) and with only 1 ticket
>and still got these 5-10 seconds with either fcgi, scgi and mod_perl on
>Apache1.3. I also checked for timeouting DNS queries but with no luck.
>
>I would really love to use RT but these numbers are of course not usable
>for production use. I'm glad another user just reported <1s per ticket
>which means that it is not broken by design.
>
>So Any ideas what could cause such a delay? 
>
>thanks,
>
>-christian-
>
>  
>




More information about the rt-users mailing list