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

[Rich West]

Dan Pritts wrote:

>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?
>  
>

Pretty much.  You have to base it upon your system load (number of 
requests), but yes.  I believe a minimum is about 3 FastCGI servers, 
with a generalized max being around 6 to 8 (and 8 is pushing it).

>In particular, does each user session use a single FastCGI or will the
>system use them in parallel to fulfill a single web hit?
>  
>

Actually, each user's *request* goes to a fastcgi server process.  It is 
similar to the way that httpd handles requests.  So, if you use a 
typical browser to pull up a page, it may contain a number of requests, 
which get spread across the fastcgi servers.

The mozilla browser's http-pipelining helps a bit, too. :)

>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.
>

Same here.. this is normal...

>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.
>  
>

I would be curious to see your mysql modifications for my own possible 
benefit. :)

>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.
>

Wow..  That should rocket on that thing. :)

I've run it on a variety of machines (Solaris, Linux), with the current 
configuration on a 1.4Ghz P3 and it is rock solid.

RequestTracker, as with any helpdesk tool that has so much 
functionality, will not draw pages as quickly as if you were browsing 
static web pages.  You will always see a bit of latency; it will not be 
instantaneous.  The reality is that you will see something in the area 
of 2-4 seconds per page draw, which is common place.

Hope this helps!
-Rich