[rt-users] RT Performance, Hardware

[Jim Meyer]

On Mon, 2002-06-24 at 01:46, 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.
> 
> 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 at wildbrain.com