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

[Dan Pritts]

Thanks for your response.

I originally started with just 1 FastCGI.  I was the only user of the
system so I don't think it was timing out waiting for that FastCGI to
become available - but it was slow as heck.

I increased it to 12 processes (based on some online docs I found) and
later, based on this list's advice, dropped it to 4.  When I dropped it
from 12 to 4 I did see a minor improvement that I attributed to caching
by the FastCGI processes, but things were still awfully slow.


Based on what I have picked up about FastCGI, I think that the goal for
tuning the number of processes running should be "enough so that there
is always one for a new user connecting, but not many more so that the
FastCGIs can cache things effectively."

Is that an accurate portrayal of things as you understand them?
In particular, does each user session use a single FastCGI or will the
system use them in parallel to fulfill a single web hit?


I am very confident that my problem is not in the database.  Simply
watching the system with "top" showed that the database was idle and
the perl mason_handler processes were eating the CPU for seconds at
a time.  Changing the mysql config from the default to a config based
on my-large.cnf made no appreciable difference other than in the
amount of RAM that mysql uses.

Since I sent my original message I have thrown hardware at the problem.
I am now running with a 2.4GHz Xeon hyperthreading CPU and things are
much better, the system is now usable. I would still not consider the
performance great.

On Tue, Oct 12, 2004 at 11:51:30AM -0400, Rich West wrote:
> 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-
> >
> > 
> >
> 


danno
--
dan pritts - systems administrator - internet2
734/352-4953 office        734/834-7224 mobile