I think I know the answer to this, but I need to ask anyway. We’ve got
an old copy of
RT running (2.0.15) and things are often slow when we have numerous
people using the system. Let me give some numbers to help put this in
perspective.
Dual Pentium 1 ghz
2 gigs of RAM
RedHat 9
By ‘numerous’ people, I mean 15+. The system will often take 20-40
seconds
(sometimes more) to render a page - viewing a queue listing is generally
the worst offender, but the system as a whole slows down.
The database is MySQL running on a separate server connected via a
gigabit connection - the database server never breaks a sweat. In a
typically week we may have 20million queries on that server, and 100 of
them take longer than 5 seconds (mysql slow-query logging is set to 5
seconds).
I realize this is a very old version, but I’m reluctant to upgrade
because 1) there’ve been some customizations to the code and 2) there
are other systems which rely on the current RT the way it is for
GET/POST interaction.
Will upgrading to the latest release (however painful) have a dramatic
improvement to the performance? Can anyone who has worked on the code
give me an idea of some of the underlying performance enhancements at
that level which would make a dramatic difference? At the moment, (perl
and mod_perl are not my primary languages), I’m having to assume the
speed is either with perl itself or with the multiple layers of
abstraction in the RT code I can see.
Will upgrading to the latest release (however painful) have a dramatic
improvement to the performance? Can anyone who has worked on the code
I can’t exactly comment, because part of our upgrade entailed moving
off MySQL and onto PostgreSQL. But our results were dramatically
slower on 3.x than on 2.x. We had a lot of work to do just to get it
working acceptably.
A
Andrew Sullivan | ajs@crankycanuck.ca
This work was visionary and imaginative, and goes to show that visionary
and imaginative work need not end up well.
–Dennis Ritchie
So you’re saying that moving from RT2 to RT3 and MySQL to PG gave you
performance hit?
What have you done to get improvements? Only indexes? Something else?
Will upgrading to the latest release (however painful) have a dramatic
improvement to the performance? Can anyone who has worked on the code
I can’t exactly comment, because part of our upgrade entailed moving off
MySQL and onto PostgreSQL. But our results were dramatically slower
on 3.x than on 2.x. We had a lot of work to do just to get it working
acceptably.
So you’re saying that moving from RT2 to RT3 and MySQL to PG gave you
performance hit?
Yes, quite a significant one. Part of the issue, though, is that the
not-MySQL support in RT is sort of an add-on. It works, but this is
fundamentally an application that was ported from MySQL to other
systems. MySQL isn’t a very database-y database, and it shows when
you’re trying to get other systems to work with applications designed
for MySQL. The developers have done a reasonable job, given that
constraint.
What have you done to get improvements? Only indexes? Something else?
Well, you really need to make your database system go fast.
There’s a lot of interaction between the interface and the database,
and not all of it is terribly efficient. If you can live with MySQL,
then I strongly suggest you stick with it. Our problem partly came
from a long user list, which made several kinds of searches really
awful. But many standard kinds of use are just fine. I will say
that the feature set compared to 2.x is way better; better, in
fact, than most systems I’ve seen.
A
Andrew Sullivan | ajs@crankycanuck.ca
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
–Brad Holland
Yes, quite a significant one. Part of the issue, though, is that the
I should note, also (thanks to someone for reminding me of this) that
3.4.5 was a siginificant improvement over its predecessor in our
environment. While I’m on the topic, I’ll also mention that our use
of RT is, uhm, a little bit clunky compared to the way it’s designed.
So those were two factors in our issues that might not be relevant
elsewhere.
A
Andrew Sullivan | ajs@crankycanuck.ca
Information security isn’t a technological problem. It’s an economics
problem.
–Bruce Schneier
We’ve got probably the opposite issue - few users (<200 I believe) but
years of ticket data. People here keep thinking that this is the
primary speed issue, and did a ticket archive last October. It didn’t
really help much (maybe 5-10% speed improvement) and we’re now back to
where we were 6 months ago anyway. The database itself is fast -
blindingly so, imo. From what I can read nearly all the queries are
cached in memory anyway, so I don’t think I can hold mysql accountable
for much of this. I just ran a dprof and got some interesting numbers.
The page took 90 seconds to come up - 58 seconds of that was
‘user+system’ time (I guess the rest was ambient and/or the dprof
overhead) - the DBIx::SearchBuilder stuff was close to 60% of the
execution time (~35 seconds).
Has anyone on the list stayed with mysql from 2->3 and noticed a speed
improvement?
So you’re saying that moving from RT2 to RT3 and MySQL to PG gave you
performance hit?
Yes, quite a significant one. Part of the issue, though, is that the
not-MySQL support in RT is sort of an add-on. It works, but this is
fundamentally an application that was ported from MySQL to other
systems. MySQL isn’t a very database-y database, and it shows when
you’re trying to get other systems to work with applications designed
for MySQL. The developers have done a reasonable job, given that
constraint.
What have you done to get improvements? Only indexes? Something
else?
Well, you really need to make your database system go fast.
There’s a lot of interaction between the interface and the database, and
not all of it is terribly efficient. If you can live with MySQL, then I
strongly suggest you stick with it. Our problem partly came from a long
user list, which made several kinds of searches really awful. But many
standard kinds of use are just fine. I will say that the feature set
compared to 2.x is way better; better, in fact, than most systems I’ve
seen.
A
Andrew Sullivan | ajs@crankycanuck.ca
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
–Brad Holland
‘user+system’ time (I guess the rest was ambient and/or the dprof
overhead) - the DBIx::SearchBuilder stuff was close to 60% of the
execution time (~35 seconds).
Well, that module still could use a rocket engine, but I think you
might find an improvement. There’s one way to find out, of course:
load it up and give it a whack. Your users will love the additional
features, I assure you. And I can say that one thing that wasn’t
bad was the very-old-ticket issue. We have all ours online, back to
2001, without trouble. That part Just Works.
A
Andrew Sullivan | ajs@crankycanuck.ca
“The year’s penultimate month” is not in truth a good way of saying
November.
–H.W. Fowler
[…]
Has anyone on the list stayed with mysql from 2->3 and noticed a speed
improvement?
Thanks!
We stayed on MySQL cutting over from rt2 to rt3 (4 privileged users,
about 200 unprivileged). With rt3.4, the speed with ~13.000 Tickets
(I know, a small number!) is OK - I never felt the need to profile. A
‘normal’ ticket loads in about 2 seconds.
We do have problems with the pathological cases (searching through
binary attachments), but those are well known (see the archives).
What is important for MySQL and PostgreSQL is proper tuning of
course. I just had to reduce the memory allocated to MySQL’s various
buffers, which slowed things down by about half a breath (sorry, no
hard scientific measures here), but the system doesn’t need to swap
continuously anymore…
Regards,
Harald
Harald Wagener
Technischer Leiter
Foote Cone & Belding
FCB Wilkens
An der Alster 42
20099 Hamburg
Germany