[rt-users] mod_perl vs fastcgi, which performs best, which is more scalable?

[Derek Suzuki]

 I've been running on FastCGI since 3.0.7.  Starting from 3.0.9 we have seen some horrendous performance problems (CPU pegging and effectively hanging the application for upwards of a minute) even on modern hardware with minimal workloads.  We were able to work around them by pre-starting multiple server processes (the perl process is actually what seems to hang), and performance has been pretty good since then.
 I did hear from one mod_perl user who said he had a similar problem, but I've never tried that configuration myself.
 For comparison, I've got a dual Xeon server with 2GB RAM and hardware mirrored SATA drives running RHEL 3.


-----Original Message-----
From: rt-users-bounces at lists.bestpractical.com on behalf of Charles Jones
Sent: Tue 6/15/2004 5:14 PM
To: rt-users at lists.bestpractical.com
Subject: [rt-users] mod_perl vs fastcgi, which performs best,which is more scalable?
 
I have an associate who has been running RT for quite some time, and has 
literally tens of thousands of tickets in the database. He mentioned 
that sometimes loading a ticket can take an extremly long time (I assume 
if it has other parent/child tickets that it has to find). I do not want 
this to eventually happen to my RT instance, so I am wondering what the 
optimal setup is.  He is using mod_perl, I am using fastcgi.  His apache 
and mysql are on solaris, mine are on linux.  Both architectures are 
SMP, but I really am more interested in optimal setups and tweaks for RT 
on the software side, rather than the OS and hardware.  In other words, 
we can probably discuss at length whether apache runs better on a 
multi-proc Solaris box or a Linux box, as well as 64bit Mysql advantages 
etc.

What I am wondering exactly is:
1. Which performs better in general, mod_perl or fastcgi? I googled for 
some benchmarks and didn't really find anything enlightening.
2. Is there anything that can be done to the RT database itself, to 
speed up a large database, short of actually deleting older tickets?  
Things like table indexes, ensuring all the numeric tables are numeric 
types, etc?
3. How aware are the RT developers of issues later down the road when 
the database gets huge? In other words, is RT3 as optimal as it can be 
as far as making the db queries as efficient as possible, or is there a 
lot of work and improvment that can/will be done in future versions?

Thanks,
-Charles Jones
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

RT Developer and Administrator training is coming to LA, DC and Frankfurt this spring and summer.
http://bestpractical.com/services/training.html

Sign up early, as class space is limited. 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20040615/a94fbc12/attachment.htm>