Performance of RT 3.02

I’m in the process of installing RT for the first time. Just wondering
what kinds of loads people are using with it. We get between 100 to 200
e-mails a day … I just wanted to see if anyone is dealing with this
kind of volume, and, if so, if there are any performance issues? We
will have 3-5 staff members on at any given time.

Thanks!

Jen

At least with PostgresQL as database it’ll be way to slow. Don’t know
about other backends. AFAIK speed enhancements are still work in
progress. I’ve got about 5000 tickets in the database and have to wait
up to a minute for certain pages to load.On Tue, 2003-06-17 at 18:02, jennyw wrote:

I’m in the process of installing RT for the first time. Just wondering
what kinds of loads people are using with it. We get between 100 to 200
e-mails a day … I just wanted to see if anyone is dealing with this
kind of volume, and, if so, if there are any performance issues? We
will have 3-5 staff members on at any given time.

Christian Zagrodnick

gocept gmbh & co. kg - schalaunische strasse 6 - 06366 koethen/anhalt
fon. +49 3496 3099112, +49 179 1463644
fax. +49 3496 3099118

signature.asc (186 Bytes)

At least with PostgresQL as database it’ll be way to slow. Don’t know
about other backends. AFAIK speed enhancements are still work in
progress. I’ve got about 5000 tickets in the database and have to wait
up to a minute for certain pages to load.

RT 3.0.3preX releases seem to significantly improve this for just about
everyone who’s tried them.> On Tue, 2003-06-17 at 18:02, jennyw wrote:

I’m in the process of installing RT for the first time. Just wondering
what kinds of loads people are using with it. We get between 100 to 200
e-mails a day … I just wanted to see if anyone is dealing with this
kind of volume, and, if so, if there are any performance issues? We
will have 3-5 staff members on at any given time.


Christian Zagrodnick

gocept gmbh & co. kg - schalaunische strasse 6 - 06366 koethen/anhalt
fon. +49 3496 3099112, +49 179 1463644
fax. +49 3496 3099118

http://www.bestpractical.com/rt – Trouble Ticketing. Free.

At least with PostgresQL as database it’ll be way to slow. Don’t know
about other backends. AFAIK speed enhancements are still work in
progress. I’ve got about 5000 tickets in the database and have to wait
up to a minute for certain pages to load.

Yikes! I’m using MySQL. So is 3.02 not ready for prime time? Should I have
installed RT 2.x instead?

Thanks!

Jen

At least with PostgresQL as database it’ll be way to slow. Don’t know
about other backends. AFAIK speed enhancements are still work in
progress. I’ve got about 5000 tickets in the database and have to wait
up to a minute for certain pages to load.

Yikes! I’m using MySQL. So is 3.02 not ready for prime time? Should I have
installed RT 2.x instead?

We ditched our RT 2.0.9 installation on Postgres for 3.0.3pre3 on MySQL,
more than 16,000 tickets, speed is not an issue, everything is at least
reasonably fast.

It’s just great software.

Cheers.

Mick

I can attest to RT 3.02 on RH 9, w/ Postgres being slow… it’s usable,
but we are just testiing it out. I’m glad to hear there are speed
improvements in the newer versions…

As a new user, I didn’t want to try to set up a pre release package
while still learning how the default install works.

Is MySQL any better with speed?

MatthewOn Tuesday, June 17, 2003, at 04:00 PM, Mick Szucs wrote:

On Tue, 2003-06-17 at 15:39, jennyw wrote:

On Tue, Jun 17, 2003 at 09:33:48PM +0200, Christian Zagrodnick wrote:

At least with PostgresQL as database it’ll be way to slow. Don’t know
about other backends. AFAIK speed enhancements are still work in
progress. I’ve got about 5000 tickets in the database and have to
wait
up to a minute for certain pages to load.

Yikes! I’m using MySQL. So is 3.02 not ready for prime time? Should
I have
installed RT 2.x instead?

We ditched our RT 2.0.9 installation on Postgres for 3.0.3pre3 on
MySQL,
more than 16,000 tickets, speed is not an issue, everything is at least
reasonably fast.

It’s just great software.

Cheers.

Mick


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Matthew Barr
mbarr@mbarr.net
Managing Partner
Datalyte Consulting, LLC.
(646) 765-6878 (cell)

Yikes! I’m using MySQL. So is 3.02 not ready for prime time? Should I have
installed RT 2.x instead?

MySQL tends to be do much finer than Postgresql. We have >1000 tickets
(on MSWin32, even) with modest hardware and runs well.

Thanks,
/Autrijus/

I’m in the process of installing RT for the first time. Just wondering
what kinds of loads people are using with it. We get between 100 to 200
e-mails a day … I just wanted to see if anyone is dealing with this
kind of volume, and, if so, if there are any performance issues? We
will have 3-5 staff members on at any given time.

We upgraded from RT1.x to RT3.0.0 at the end of March (installed RT3 on a
different machine and didn’t import the old tickets). Approximately 80
days later, we have 16,000 tickets (averages to 200 a day). Response is
reasonable on an older PIII system (I think around 500mHz, 512MB RAM and
SCSI drives) running FreeBSD 4.x. We have had problems with FastCGI
constantly timing out after a few days of use. We finally gave in and
added a cron job to restart apache every morning.

I would suggest a very fast machine with lots of RAM and SCSI drives…

Spam Trap Mail Key: ASK and you shall receive

We upgraded from RT1.x to RT3.0.0 at the end of March (installed RT3 on a
different machine and didn’t import the old tickets). Approximately 80
days later, we have 16,000 tickets (averages to 200 a day). Response is
reasonable on an older PIII system (I think around 500mHz, 512MB RAM and
SCSI drives) running FreeBSD 4.x. We have had problems with FastCGI
constantly timing out after a few days of use. We finally gave in and
added a cron job to restart apache every morning.

That’s good to know – we’ll have almost the same volume. Anyone have
that kind of volume who has maybe a year’s worth of tickets? I’m just
concerned about what’s going to happen once we get to 50,000 tickets or
so. I guess we could purge the database of old tickets or something if
it slows down, but it would be nice if we could keep tickets around for
analysis.

Jen