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

[Peter Silver]

On Wed, 2004-06-16 at 10:14, Jesse Vincent wrote:
> 
> On Tue, Jun 15, 2004 at 05:14:14PM -0700, Charles Jones wrote:
> > 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?
> 
> What's huge? We've got sites with 750,000 tickets in their database.
> Each and every site will have different scalabiltiy concerns. If your
> site is getting huge, you're going to want to spend time tuning the
> system to meet your needs or have us do so on your behalf.  

We've just hit 200,000 tickets in our RT database, and our install is
very responsive with 10 - 15 operators using RT at any given time;

    Logging in & displaying stats for 50 queues  :  2 - 3 secs
    Entering a queue with 20 tickets             :  2 secs
    Displaying a ticket with several responses   :  1 - 2 secs

Our system specs aren't anything very special;
  CPU:      2.8ghz Intel P4
  RAM:      2gb
  RT:       3.0.11
  Apache:   1.3.31
  mod_perl: 1.29

We hit major performance problems once we upgraded from the RT 2.0.x to
3.0.x series.  The following are things that seem to have helped in
speeding up the system;

1.  We were running the system on IDE drives.  We migrated the DB data
    onto SCSI drives.

2.  Upgraded the amount of RAM from 1gb to 2gb.

3.  Tweaking of MySQL config - trial & error to some extent.

4.  SWAP was running on a single IDE drive - we defined several smaller
    swap partitions, one on each physical drive.

After the above 4, and a few RT upgrades as newer versions were
released, the system was running very nicely.  Of the above 4 changes, I
think we saw the most performance gain from the tweaking of MySQL &
additional RAM.

The only remaining problem was that RT would get less & less responsive
throughout the day, until apache was restarted.  Changing
MaxRequestsPerChild in apache from 0 to 100 has fixed this problem for
us.

I'm sure we made a few additional tweaks, but I cannot recall these off
the top of my head.

The next step for us, is to remove all deleted tickets from our
database.  Our management's decision is that we cannot outright delete
anything for 5 years, so we have to transfer all deleted tickets to a
holding database, where each ticket can be permanently purged after it's
reached 5 years.. fun!


Regards,

Peter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20040617/54fd315a/attachment.sig>