Rt 2.09 / 2.0.13 performance (& SQL schema)

RT Users
1

hi

i remember reading a while back(many moons ago …) there was a newer ver
of RT that had an updated sql schema that was supposed to improve performance
i was wondering if I already had this schema in 2.09 or got it in my 2.13
upgrade today. I did do /usr/local/rt/etc/insertdata 2.0.9 and it inserted
some new things into the db …

but the performance seems the same as 2.0.9. for new tickets it is fast but
for older tickets it can get pretty slow. I have 2 configurations:

Main production config:
RT 2.0.9
MySQL 3.23.40 compiled with many performance options
apache-ssl+mod_perl (DSO module)
P3-650 w/1GB ram, Ultra2 (80MB/s) SCSI drives
Debian woody (3.0)

soon to be production config(hopefully) 2 servers:
RT 2.0.13
apache-ssl+mod_perl (DSO module)
P3-450 w/512MB ram and Ultrawide (40MB/s) drive
Debian woody(3.0)

SQL server (already in production with several other DBs):
Dual P3-600 1GB Ram, Ultra2 (80MB/s) SCSI drives
MySQL 3.23.42 with many performance options as described in mysql docs
Debian Potato(2.2r5)

RT server is on the same 100mbit switched lan and connected to the SQL server.
the users of RT say the performance is about the same whether or not the DB
is local, so it doesn’t appear that stunnel has any negative effects on it that
are noticable. I did see cpu usage spike for mysql when loading a real old
ticket on the SQL server(rt 2.0.13). my MySQL server is quite fast, this
particular server i have tested using another web-app called PureSecure
(formarlly DEMARC), and it made extensive use of mysql, my databases could
run 500+MB and it would still be fast, by contrast my rt2 db is 24MB(in
text-dumped format) and it’s much slower …my Puresecure systems at times
logged up to 40,000 network alerts per hour, and the server didn’t even
hiccup.

any performance tips?

thanks for the great work on rt, its a real useful app, I’m glad i found it
when I did.

sofar i think we have about 800 tickets. though I haven’t used rt much I just
see ticket id#s up to #809, not sure if older ones can be deleted …

nate

Nate Amsden
System Administrator
GraphOn

2

Nate Amsden wrote:

any performance tips?

couple more things …

i searched through the archives and jesse said at one point to someone to
upgrade DBI::SearchBuilder to 0.46-test1 which helped that person’s performance
a lot. my system is currently running DBI::SearchBuilder 0.48-1(Debian package).

there is usually 1 person at a time using the system, i would guess that
maybe 5 people total use it. so load is light, new tickets come up very
fast(within
a second or so), old tickets can take sometimes 35-45 seconds. i tried searching
the contrib stuff for any kind of cleanup script that may clean up the db
of old data, but couldn’t find anything.

another post mentioned using a caching proxy infront of the webserver to
reduce load, but since my load is so light anyways i don’t think it would help.
the users are connected to the server over 100baseT lan. on the main
production server i also run another system - ezPublish which uses mod_php
and mysql, it too is very fast, but it also doesn’t get much traffic, maybe
30 hits a day(most are from me). the new system is rt-only, but the performance
is the same on both.

as for mysql config:

I am using these runtime options with mysql:
–skip-locking -O key_buffer=128M -O table_cache=1024 -O sort_buffer=8M -O
record_buffer=5M

I used these performance-related compile time options with mysql:
–with-client-ldflags=-all-static --enable-assembler
–with-mysqld-ldflags=-all-static

i’ve seen posts here(been lurking here since maybe july/august 2001) about
people
having tens of thousands of tickets, some having dozens of concurrent users …so
I
am uncertain what is different about my situation, maybe rt magically gets
faster
with more load ? :confused: again our db has less then 900 tickets generated. running
rt 2.0.13(on a test system with the same db data), and rt 2.0.9 on the main
production system. OS is debian gnu/linux 3.0

i can’t find much more tuning suggestions via the list archives …the FAQ
mentions
a couple things but doesn’t say how to go about checking the SQL schema or
upgrading
it(if i was not already running the current schema …)

thanks again.

nate

Nate Amsden
System Administrator
GraphOn