RT Performance, Hardware

Daniel_K · June 22, 2002, 10:51am

Hi all,

I’m trialling R/T on a spare machine at the moment - but one problem I have
with it is that it’s really slow.

I’m running it on Postgres. I haven’t used mod_perl or Mason before, and I
haven’t done any performance customisation with Postrgres (apart from
running vaccuum nightly), so this is a stock-standard install.

I’m also running it on some pretty modest hardware - a P100 with 128MB RAM,
running FreeBSD 4.5. I’ve scaled back Apache’s start servers and spare
servers settings a little.

So given that I haven’t done anything to tweak the performance, and it’s
probably running on an underpowered machine - I’m not expecting brilliant
performance.

However, it takes >40 seconds just to display a ticket with a single
comment!

What sort of hardware are people running R/T on? Is Postgres likely to be
very much slower than MySQL? What sort of hardware should I expect to have
to use for reasonable performance? Are there any performance tweaks people
can suggest?

Thanks in advance,

Daniel.

Harald_Kollera · June 24, 2002, 8:04am

Hi,

Daniel K wrote:

So given that I haven’t done anything to tweak the performance, and it’s
probably running on an underpowered machine - I’m not expecting brilliant
performance.

However, it takes >40 seconds just to display a ticket with a single
comment!

What sort of hardware are people running R/T on? Is Postgres likely to be
very much slower than MySQL? What sort of hardware should I expect to have
to use for reasonable performance? Are there any performance tweaks people
can suggest?

we run it on a linux box (woody-debian, Pentium III with 1 processor
750MHz, 256MB Ram) with postgres. And it seems sufficient. But from my
experience RT is slow as a snail if the mailing system is not well
configured.

Harald

Dr. Harald Kollï¿½ra
Professional Services
fun communications GmbH
Brauerstrasse 6 76135 Karlsruhe Germany
Tel: +49 721 964480 Fax: +49 721 96448-299
email: harald.kollera@fun.de http://www.fun.de/

I trust in http://www.keytrust.de

Timo_A_Hummel · June 24, 2002, 8:14am

we run it on a linux box (woody-debian, Pentium III with 1 processor
750MHz, 256MB Ram) with postgres. And it seems sufficient. But from my
experience RT is slow as a snail if the mailing system is not well
configured.

The performance of RT also strongly depends on how many queues and
tickets are in the system. We run an RT system with >50 queues, and the
Quicksearch element (which shows the amount of new/open and resolved
tickets) takes almost 4 seconds, while as other elements go trough
pretty quick.

Regards,
Timo

Manfred_Hui · June 24, 2002, 8:46am

It should only take a few seconds to load a ticket, (we have around 30000
tickets, mysql, P3 600, 512 mb ram)

Check that you have indexed the tables correctly, especially Tickets,
Transactions and Attachments.

Upgrading to the latest version may also offer speed improvements, as I
discovered (from 2.0.8 to 2.0.13)

Manfred.From: “Harald Kollera” harald.kollera@fun.de
To: “Daniel K” dmk@sych.org
Cc: rt-users@lists.fsck.com
Sent: Monday, June 24, 2002 4:04 PM
Subject: Re: [rt-users] RT Performance, Hardware

Hi,

Daniel K wrote:

So given that I haven’t done anything to tweak the performance, and it’s
probably running on an underpowered machine - I’m not expecting
brilliant
performance.

However, it takes >40 seconds just to display a ticket with a single
comment!

What sort of hardware are people running R/T on? Is Postgres likely to
be
very much slower than MySQL? What sort of hardware should I expect to
have
to use for reasonable performance? Are there any performance tweaks
people
can suggest?

we run it on a linux box (woody-debian, Pentium III with 1 processor
750MHz, 256MB Ram) with postgres. And it seems sufficient. But from my
experience RT is slow as a snail if the mailing system is not well
configured.

Harald

–
Dr. Harald Kollï¿½ra
Professional Services
fun communications GmbH
Brauerstrasse 6 76135 Karlsruhe Germany
Tel: +49 721 964480 Fax: +49 721 96448-299
email: harald.kollera@fun.de http://www.fun.de/

I trust in http://www.keytrust.de

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

Jim_Meyer · June 24, 2002, 2:06pm

It should only take a few seconds to load a ticket, (we have around 30000
tickets, mysql, P3 600, 512 mb ram)

Check that you have indexed the tables correctly, especially Tickets,
Transactions and Attachments.

Upgrading to the latest version may also offer speed improvements, as I
discovered (from 2.0.8 to 2.0.13)

When we were having such speed issues, it turned out that we didn’t know
enough about maintaining and optimizing databases (PostgreSQL in our
case). Here’s a few things I’d look at:

Logging: we put our database server in full verbose mode as we were
testing RT before rollout … and forgot to decrease the logging level.
That hurt quite a lot, causing an average four separate disk writes per
interface click.
Vacuuming and Analysis: we knew that vacuuming the database would
remove deleted rows, but reasoned that we didn’t need to do that as we
were never deleting any rows. Well, it turns out that the way postgresql
implements transactions is very much like a delete. Our ticket display
times were on the order ~20 seconds; after a VACUUM ANALYZE command,
they’re now happily around 2-3 seconds. We now vacuum daily.
Optimization: it seems that a good rule of thumb is to be sure that
there are enough buffers allocated to your server to contain all of your
more static tables (keywords, scripactions, etc.) and some reasonable
number of rows from your dynamic tables (tickets, attachments,
transactions, etc.). We’ve found that for our volume of tickets, one
week’s worth of dynamic table rows seems to serve us well.
Specialization: if the above still doesn’t get you there, it could be
that your server is too underpowered to handle both a database and a
webserver. Separating the two should allow you to tune each machine
separately, which can help performance.

Good luck!

–j

p.s. There’s good info in the list archives; search for “postgres” and
“speed”
Jim Meyer, Geek At Large purp@wildbrain.com

Bruce_Campbell · June 24, 2002, 2:23pm

we run it on a linux box (woody-debian, Pentium III with 1 processor
750MHz, 256MB Ram) with postgres. And it seems sufficient. But from my
experience RT is slow as a snail if the mailing system is not well
configured.

The performance of RT also strongly depends on how many queues and
tickets are in the system. We run an RT system with >50 queues, and the
Quicksearch element (which shows the amount of new/open and resolved
tickets) takes almost 4 seconds, while as other elements go trough
pretty quick.

Hrm. This is a wee bit on the bad side. This could be fixed by caching
the number of queues per ticket status every [regular time interval], and
having simple Scrip-base {in,de}crements on any status change.

You lose absolute reliability of this output when lots of updates occur
inside [regular time interval], but gain 4 seconds per load of the home
page, which if you’ve got 50 queues visible to most people, is a lot.

Regards,

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B                      Operations

Jesse_Vincent · June 24, 2002, 2:27pm

Enhancements to the ACL system coming in the next major release should
significantly improve this. Soon, we’ll have API calls for all the primitives
an ACL system should have.

JOn Mon, Jun 24, 2002 at 04:23:56PM +0200, Bruce Campbell wrote:

On Mon, 24 Jun 2002, Timo Hummel wrote:

The performance of RT also strongly depends on how many queues and
tickets are in the system. We run an RT system with >50 queues, and the
Quicksearch element (which shows the amount of new/open and resolved
tickets) takes almost 4 seconds, while as other elements go trough
pretty quick.

Hrm. This is a wee bit on the bad side. This could be fixed by caching
the number of queues per ticket status every [regular time interval], and
having simple Scrip-base {in,de}crements on any status change.

You lose absolute reliability of this output when lots of updates occur
inside [regular time interval], but gain 4 seconds per load of the home
page, which if you’ve got 50 queues visible to most people, is a lot.

Regards,

–
Bruce Campbell RIPE
Systems/Network Engineer NCC
www.ripe.net - PGP562C8B1B Operations

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

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

Nate_Amsden · June 25, 2002, 9:12pm

Manfred Hui wrote:

It should only take a few seconds to load a ticket, (we have around 30000
tickets, mysql, P3 600, 512 mb ram)

Check that you have indexed the tables correctly, especially Tickets,
Transactions and Attachments.

does this apply to only postgres ? i have a system running mysql and with 1000
tickets its dog slow, some tickets take over a minute to load. p3-600 1gb ram.

can you point me to docs that talk about indexing the tables ? i haven’t used
rt directly much yet(others on the network do) but i have been maintaining
the ‘back end’ for a while.

thanks!!

nate

Nate Amsden
System Administrator
GraphOn

Robin_Lee_Powell · June 26, 2002, 5:19pm

Manfred Hui wrote:

It should only take a few seconds to load a ticket, (we have around 30000
tickets, mysql, P3 600, 512 mb ram)
^^^^^

Check that you have indexed the tables correctly, especially Tickets,
Transactions and Attachments.

does this apply to only postgres ?

That seems unlikely.

-Robin

Robin Powell's Old Home Page BTW, I’m male, honest.
le datni cu djica le nu zifre .iku’i .oi le so’e datni cu to’e te pilno
je xlali – RLP http://www.lojban.org/

Manfred_Hui · July 2, 2002, 2:59am

Manfred Hui wrote:

It should only take a few seconds to load a ticket, (we have around
30000
tickets, mysql, P3 600, 512 mb ram)

Check that you have indexed the tables correctly, especially Tickets,
Transactions and Attachments.

does this apply to only postgres ? i have a system running mysql and with
1000
tickets its dog slow, some tickets take over a minute to load. p3-600 1gb
ram.

No, We use mysql as well.

To find out, connect to mysql and run this command:

and

You should see something like the above.

If the indexes haven’t been created, create them from the schema file
/usr/local/src/rt2/etc/schema.mysql

can you point me to docs that talk about indexing the tables ? i haven’t
used

Manfred_Hui · July 2, 2002, 3:06am

By the way, please backup your data before playing with the indexes.

Manfred.From: “Nate Amsden” subscriptions@graphon.com
To: rt-users@lists.fsck.com
Sent: Wednesday, June 26, 2002 5:12 AM
Subject: Re: [rt-users] RT Performance, Hardware

Manfred Hui wrote:

It should only take a few seconds to load a ticket, (we have around
30000
tickets, mysql, P3 600, 512 mb ram)

Check that you have indexed the tables correctly, especially Tickets,
Transactions and Attachments.

does this apply to only postgres ? i have a system running mysql and with
1000
tickets its dog slow, some tickets take over a minute to load. p3-600 1gb
ram.

can you point me to docs that talk about indexing the tables ? i haven’t
used
rt directly much yet(others on the network do) but i have been maintaining
the ‘back end’ for a while.

thanks!!

nate

–
Nate Amsden
System Administrator
GraphOn
http://www.graphon.com

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

Nate_Amsden · July 2, 2002, 4:07pm

Manfred Hui said:

By the way, please backup your data before playing with the
indexes.

excellent! thanks! i’ll see if i can try this today, i have
a 2nd rt installation thats on another DB server i can experiment
on with semi-recent data from the first installation.

where did you learn how to do that? someone on the list or was
there a doucment somwhere? last i checked the FAQ it mentioned
updating the schema but did not give any information on how to
do this. my last request on how to update the schema(month or
so ago) got no response.

thanks a lot for this!!

nate

Nate Amsden
System Administrator
GraphOn
(Sent using Squirrelmail! 1.2.4)

Nate_Amsden · July 2, 2002, 5:45pm

Nate Amsden wrote:

Manfred Hui said:

By the way, please backup your data before playing with the
indexes.

excellent! thanks! i’ll see if i can try this today, i have
a 2nd rt installation thats on another DB server i can experiment
on with semi-recent data from the first installation.

i ran a couple crude tests with this one ticket that takes a while,
results are without the indexes, takes 45 seconds to load, with the
indexes it takes 16 seconds to load. much improved!! in addition,
the system with the indexes isn’t even running mysql locally, its
going accross a 100baseT network via SSL. so that adds some latency
to the connection, still almost 3 times faster then the one running
mysql locally(through sockets even)

and if anyone else is reading this thread for hints, i manually executed
the SQL strings one by one instead of importing the whole file, mysql
complained about things already existing when i tried to load the whole
file.

thanks again

nate

Nate Amsden
System Administrator
GraphOn