Ideal RT setup

Hi folks,

We have a pretty big RT setup - something around 70,000 tickets, with
40-50,000 coming in per year, and getting faster.

For this we’re running RT 2 on MySQL 3.23.52, Apache 1.3.26 and mod_perl.

I’m now looking into moving the system to it’s own server, and it seems
like a good opportunity to try out a new setup, so the question is what
are the best supporting packages for RT?

I’ll be trying out a few things - RT 3.0.3 and the latest 2.0.x release.

MySQL (3 or 4?) or PostgreSQL?

mod_perl or FastCGI?

Apache 1.3 or apache 2?

I’d be very grateful for any opinions or (even better) figures from
anyone who’s tried the different possiblities. I’ll probably end up
doing a load of benchmarks, and if I do I’ll certainly post the results.

Daniel Foster
Technical Director
34SP.com

±le 25/06/2003 11:56 +0100, Daniel Foster écrivait :
| Hi folks,
|
| We have a pretty big RT setup - something around 70,000 tickets, with
| 40-50,000 coming in per year, and getting faster.
|
| For this we’re running RT 2 on MySQL 3.23.52, Apache 1.3.26 and mod_perl.
|
| I’m now looking into moving the system to it’s own server, and it seems
| like a good opportunity to try out a new setup, so the question is what
| are the best supporting packages for RT?
|
| I’ll be trying out a few things - RT 3.0.3 and the latest 2.0.x release.
|
| MySQL (3 or 4?) or PostgreSQL?
|
| mod_perl or FastCGI?
|
| Apache 1.3 or apache 2?
|
| I’d be very grateful for any opinions or (even better) figures from
| anyone who’s tried the different possiblities. I’ll probably end up
| doing a load of benchmarks, and if I do I’ll certainly post the results.

I use PostgreSQL (with small tunings mostly growing buffers).
apache 1.3 and fastcgi. I used mod_perl, and well, the fact that it was not
possible to jail virtualhosts from the others (I could access RT’s
components through another vhost) made me consider and adopt fastcgi.

Mathieu Arnold

I use PostgreSQL (with small tunings mostly growing buffers).
apache 1.3 and fastcgi. I used mod_perl, and well, the fact that it was not
possible to jail virtualhosts from the others (I could access RT’s
components through another vhost) made me consider and adopt fastcgi.

While that is a disadvantage of mod_perl, it has the benefit of
being able to detect when the user’s browser has disconnected and can
abort things. FastCGI can’t.

If that kind of security is important to you, you may find yourself
happier with with each mod_perl tool running in a seperate apache1
instance, mod_proxied by a front end apache2.

-R

I use PostgreSQL (with small tunings mostly growing buffers).
apache 1.3 and fastcgi. I used mod_perl, and well, the fact that it was
not possible to jail virtualhosts from the others (I could access RT’s
components through another vhost) made me consider and adopt fastcgi.

While that is a disadvantage of mod_perl, it has the benefit of
being able to detect when the user’s browser has disconnected and can
abort things. FastCGI can’t.

If that kind of security is important to you, you may find yourself
happier with with each mod_perl tool running in a seperate apache1
instance, mod_proxied by a front end apache2.

Since the box will be doing very little apart from this RT instance (and
certainly no other web services) that’s not important to us - raw performace
is :slight_smile:

Daniel Foster
Technical Director