We have some performance problems in RT, so I read this about running more fcgi prosesses, and figured I could give it a try.
But where (and what) should I write to increace the process number? Is it in the httpd.conf file?
Hilde
-----Opprinnelig melding-----Fra: rt-devel-bounces@lists.bestpractical.com [mailto:rt-devel-bounces@lists.bestpractical.com] På vegne av Matt Knopp
Sendt: 13. mai 2004 17:59
Til: Hans K; rt-devel@lists.bestpractical.com
Emne: Re: [Rt-devel] No multithreading?
You should also try running more fcgi processes. The default number of
processes is something silly like 1 process. In this case each request
is going to be waiting for previous N requests to finish. Run more and
you should see a fair bit better performance.
I was running on a single cpu P3/700 for quite a while. We had around
10 people using RT and almost never saw timeout issues; the few times
we did were when people tried to view very big tickets that took more
then 30seconds to display.
Eg:
FastCgiServer -processes <4|6|N>
Also unless you are using the perl based process manager [which you
surely aren’t since I don’t think I ever submitted it to jesse] you
will also want to delay how quickly each process starts up. Initing
a fcgi process is fairly expensive.
Eg:
FastCgiServer -processes --init-start-delay
I think I have my delay set to either 30 or 45 seconds.
Matt
Rt-devel mailing list
Rt-devel@lists.bestpractical.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel
We have some performance problems in RT, so I read this about running more fcgi prosesses, and figured I could give it a try.
But where (and what) should I write to increace the process number? Is it in the httpd.conf file?
In my httpd.conf file i had this line:
FastCgiServer /usr/rt3/bin/mason_handler.fcgi
I changed it to this:
FastCgiServer /usr/rt3/bin/mason_handler.fcgi -idle-timeout 300
-processes 4 -init-start-delay 30
(On one line)
It did wonders here… Still waiting for some traffic to really get
a look at wether or not it solved the problems completely.
But it sure did get faster!
-HK
I changed it to this:
FastCgiServer /usr/rt3/bin/mason_handler.fcgi -idle-timeout 300
-processes 4 -init-start-delay 30
(On one line)
It did wonders here… Still waiting for some traffic to really get
a look at wether or not it solved the problems completely.
But it sure did get faster!
But as a side note:
Before, the perl process used 20MB ram on idle.
Now there are 4x20MB used, so memory starved boxes should probably
not run too many processes.
-HK
FastCgiServer /usr/rt3/bin/mason_handler.fcgi -idle-timeout 300
-processes 4 -init-start-delay 30
(On one line)
It did wonders here… Still waiting for some traffic to really get
a look at wether or not it solved the problems completely.
But it sure did get faster!
Well, this is the single best performance improvement for RT3 that
I know of…
I did not tell my co-workers that I changed anything, but today several
of them has commented on how fast en error-free RT has been today.
Also, RT no longer switches to the alternative “theme” with white
background and generally less fancy design. It seems like it did so
whenever there were more than one request at a time. Is this a
“feature”?
And Average cpu load has went down from ~12% to ~3%. I don’t understand
why the cpu load should go down, but I guess it might have to do with
there beeing several requests on a single process.
So please put this bit of knowledge into a faq or even the
installation guide for those using rt w/fastcgi.
I also tried this trick on a customer server that uses fastcgi and it
improved performance by a large degree there too…
-HK
Right, so I should get around to giving jesse my changes to make RT use
a perl based fcgi process manager rather then the standard one. Having
the fcgi process manager in perl has two main advantages:
-
Processes init a great deal faster because perl is only having to
suck in and compile all the modules once, then it forks sharing
that data w/ the child processes; viz-a-viz doing this N times,
where N is equal to the number of servers running.
-
Memory usage is a bit less offensive since common non-changing
bits will be available via the parent. See copy-on-write, etc.
–Matt
The minimal theme you are talking about is likely because RT didn’t
finish sending its stylesheet due to a timeout or whatever.
CPU load is likely down because you don’t have a bunch of in bound
requests sitting in a tight loop waiting to see if the fcgi process
is read yet.
Matt