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

[Dan Pritts]

On Tue, Oct 12, 2004 at 02:43:04PM -0400, Rich West wrote:
> 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.

I am guessing here but I imagine that the frame containing the ticket
diary is a single http request.  This is where it's so slow.

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

Look at the example my.cnf files that come with the mysql distribution.
On my red hat system they are:

    ~@basie% ls /usr/share/doc/mysql-server-3.23.58/
    my-huge.cnf  my-large.cnf  my-medium.cnf  my-small.cnf

I think my-small is the default.  I took my-large.cnf and tweaked
it a little so it didn't use quite so much RAM but it still uses plenty.

Didn't make a difference; I had fewer than 100 tickets in the DB.  I'm
sure it *will* make a difference as my database grows.

> >the perl mason_handler processes were eating the CPU for seconds at
> >a time.
> 
> Same here.. this is normal...

Just to clarify, a mason_handler would eat the CPU for several seconds at
a time FOR EACH TICKET I OPENED.  I'm not just saying that these processes
ate CPU in general.

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

Your response is interesting - it's all a matter of expectations, I guess.
2-4 seconds is what I get now, depending on the size of the ticket
diary.  It was more like 5-10 seconds per page.  

I don't know what all mason_handler is doing, but IMO, having done some
amount of this kind of programming myself, it is awfully slow at what
it does.  It just shouldn't be taking 5 CPU seconds on a 600MHz CPU to
render a single HTML page.

that said, I'm not volunteering to dig into the RT code base & fix it
by myself, although i was hoping to provide useful feedback and testing
to others working on the problem.  (this is why i haven't said anything
about this on the list for the last several weeks).

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