When an owner is "out of office"

RT Users
21

Maren,

You trolled the list by vaguely complaining about speed and quality, but now
the real issue comes to light, the install and configuration is not easy
enough for you. It seems to me you have forgotten the old adage: fast, good,
cheap, pick any two.

There is an inverse relationship between features and performance. If you
don’t want to spend tens of thousands of dollars to have a consultant design
a PHP system for you or for a contractor to tweak your setup for you, there
are few other options outside of RT. Even if you were to build a PHP system
from scratch, it most likely would not have the features and performance of
this mature product.

Please email me if/when you find a ticketing systems that is easier and
faster than RT. I am genuinely curious because I have not been able to find
one myself.

GeorgeOn Tuesday 20 August 2002 04:13 am, Maren S. Leizaola wrote:

On Tue, 20 Aug 2002, Dave Rolsky wrote:

On Tue, 20 Aug 2002, Maren S. Leizaola wrote:

Well I’ve optimized the tables when stuff has been deleted but other

than

that I am using mysql default installation. A totally dedicated

machine.

The default mysql config uses very little memory and doesn’t take
advantage of multiple processors as well as it could. Actually tuning
MySQL can have a big impact.

I’d also recommend to anyone that they either use Mason 1.05 or

1.1201,

but not 1.10 or 1.11. 1.12 is also fine except it doesn’t work with

Perl

5.00503. The 1.10 and 1.11 releases have memory leaks that can suck

up

some decent memory, so up- or down-grading is definitely recommended.

If

you’re not using Mason for other development, there’s little reason to
upgrade from 1.05 for those currently using . 1.12 does offer a lot of
cool new features, but it’s also slower.

Of course, the chances that Mason was the bottleneck in Maren’s case

are

very small, since RT is most likely going to be DBMS-bound once more

than

a small number of tickets have been created.

Dave,
Maybe I am picky our just a lazy admin, but I believe that
decent
system sould be maintainable, should be able install them in a snap,
reconfigure them, see what it is doing. You should be able to rebuild in
under one hour or less from nothing to live.

This was what I was referring to that RT2 has gone in the wrong
direction.
The installation is a nightmare if you compare it to just about any
other
Open source system I have had on my machines during the past 8 years…

Look at what you have above, you have to tune, mysql, mason, the right
version, make sure that mode perl does this, make sure that apache kills
the process after etc…

I don’t doubt that you guys love it and without it you would struggle.
Well maybe it is just me. I like systems software like postfix, Nuke,
that
do their job and let me get on with what I should be doing.

Cheers,
Maren.

-dave

/==================
www.urth.org
we await the New Sun
==================/

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

22

The disks are idle, the HTTP deamons eat CPU like there is no
tomorow, and they inflate themselves like zepplins, even with only one
user.

That’s sure more than you said the first time, which was roughly “RT
sucks”.

It sure is.

I also think that RT UI is designed for large teams and the number of
clicks at the interface are execessive for smaller support teams. Less
clicks more speed more e-mails out. With RT1 we could respond about 10% of
e-mails in under 5 mins, as it was quick and nimble.

So why aren’t you using RT1?

No support for MIME attachments, not being able to display chinese Big5/GB
Code e-mail. If it had those features I would be a happy camper.

Maren.

23

Please email me if/when you find a ticketing systems that is easier and
faster than RT. I am genuinely curious because I have not been able to find
one myself.

I just came from Mantis (mantisbt.sf.net) which is all PHP and is
fairly snappy speedwise, but not nearly as featureful. You can even
reverse-engineer my import-mantis script (that Jesse hasn’t yet put
up in addons, nudge nudge) to go from RT tickets to Mantis, if you’re
so inclined.

xoxo,
Andy

‘Andy Lester andy@petdance.com
Programmer/author petdance.com
Daddy parsley.org/quinn Jk’=~/.+/s;print((split//,$&)
[unpack’C*‘,"n2]3%+>"34.’%&.‘^%4+!o.’"])

24

At 02:36 PM 8/20/2002 +0800, you wrote:

Dear All,
Much regretably I’ve had to pull RT2 out.

OK.

For us even a machine
with 2 cpus, raid, 512MB RAMwith 5000 tickets in the database (99% of
which were closed) the system would take ages to refresh the display.

I’ve had similar problems when users click the refresh button too much.
They get frustrated with the speed, and click it again. This causes another
MySQL process to get started, and the system sucks more resources.

I’m not saying this is your issue, but that’s an issue I’ve run across.
It’s the only speed issue I’ve seen. I’ve got over 10,000 tickets (mostly
closed) on a single PIII 800 with 512mb ram and a dual EIDE hard drive on
RH Linux 7.2, running software RAID. Not only that, this same machine runs
our twiki, big brother, bug tracking system (with postgresql backend) and
MRTG. It’s a fairly loaded system and has great performance… EXCEPT when
the users abuse it.

I also find it highly interesting that this is the only message I see from
you in my archive. I’ve got a fairly complete archive all the way back to
February, and this message is the first from your email address.

Did you ask for help?

Can someone recommend something light and fast for a very small work
group.

RT2 is the best there is. I’ve looked at several systems (both free and
not-so-free) and RT2 was the best, hands down.

Anyway cheers, I hope RT2 becomes usable in the future.

Maybe you should fight with bugzilla for a while and find out why we like
RT. You sound like some of the users I’ve helped. They want software like
Kleenex. Pull it out of the box and it works. Unfortunately, if you treat
software like Kleenex, it usually lasts about as long.

Russ Johnson

I have seen the future and it is just like the present, only longer.
– Kehlog Albran

25

Well, I think most of that stuff is to tune for ultimate speed. It’s
probably not necessary, unless maybe you’re running slower hardware,
which you’re not. Most people probably don’t tune to that extent, but I
could be wrong.

The Apache killing process thing though, that’s a mod_perl thing.
Anything that uses mod_perl would probably have the same problem. It’s
the only thing I’ve ever done to get acceptable speeds, which I would
qualify as definitely less than 3-10 seconds. It’s worth trying, just to
see if it’s a Quick Fix™, as it was for us. If not, sorry for wasting
your time.

As I said, when we first used tested RT, there was no speed problem.
After the first weekend/week when we basically filed 1000 tickets, all
the requests had bogged down mod_perl somewhat. In another week or two,
when it had bogged down more and everyone said wtf, I changed the number
of requests for Apache child processes. Problem gone…

Oh, and Dave, please chill out. :slight_smile: 5 angry emails saying “you configured
it wrong” isn’t too much more effective than 1 and tends to alienate
newbies.

The other ticketing system we tried was Keystone (after looking for even
a halfway decent one). Another department was using it unmodified for a
while, while my department only looked at the code in order to see if it
could be hacked to suit our purposes. Try modifying that beast. Some of
the ugliest PHP I have ever seen. And in terms of functionality, well,
it just didn’t cut it… And is it even updated anymore?

O- ~ARK

26

Maybe I am picky our just a lazy admin, but I believe that decent
system sould be maintainable, should be able install them in a snap,
reconfigure them, see what it is doing. You should be able to rebuild in
under one hour or less from nothing to live.

It sounds like you’re lazy. Despite what Larry Wall says, it isn’t
always a virtue.

Yes, it’d be super-cool if RT analyzed your mysql config and told you
“hey, your config is weak and without honor”, but that’d be a hell of a
lot of work for Jesse with little payoff, since most people who want to
run RT for a large set of tickets are going to take the time to do their
homework.

Alternately, I know Jesse offers commercial support. I’m sure he’d be
happy to take your money in exchange for setting up RT for you in a
well-optimized way for your machine.

But to expect RT to magically configure MySQL, and possible Apache too, in
an optimized way, considering the ridiculously large variation in
hardware, OS, Perl versions, Mason versions, mod_perl versions, and so on
that RT supports (largely because its written in Perl and works with
mod_perl) is definitely a sign of serious crack abuse, as I believe David
Troy suggested earlier.

And of course, even with your whiny, rude email to this list, you’ve
already gotten lots of good solid suggestions on improving performance.
Imagine the positive response you would have gotten if you’d acted like
less of a prick!

This was what I was referring to that RT2 has gone in the wrong direction.
The installation is a nightmare if you compare it to just about any other
Open source system I have had on my machines during the past 8 years…

Uh, yeah, whatever. I have installed much Free Software, and while I
installed RT via the debian package (which isn’t as good as it could be),
I can’t imagine that the source install is worse than many things I’ve had
to deal with in the past.

Look at what you have above, you have to tune, mysql, mason, the right
version, make sure that mode perl does this, make sure that apache kills
the process after etc…

All of which can be summarized in a very few lines.

  1. Don’t use the default mysql config. Check out the examples that come
    with mysql and modify one of those to suit.
  2. Use Mason 1.05, 1.12, or 1.1201.
  3. Don’t set MaxRequestPerChild to 0, set it to some decent-sized number
    (like 500 or 1000)
  4. Use the most recent mod_perl that you can easily install (Debian’s
    current stable version is 1.26, and is probably fine. Other GNU/Linux
    distros may vary).

Of those, the only one that requires more than a few minutes work
(assuming you don’t plan to compile a new mod_perl by hand) is #1, which
would take you about 20-40 minutes at best, assuming you have some idea of
the current load on the machine (can’t give mysql all of you free
memory).

I don’t doubt that you guys love it and without it you would struggle.
Well maybe it is just me. I like systems software like postfix, Nuke, that
do their job and let me get on with what I should be doing.

Good, go away.

This discussion can at least be in the archives for anyone else who’s
struggling. Maybe they’ll take the time to read it and try a few things
out before whining about software provided to them for free (remember, if
you want professional support, it’s available at very reasonable rates).

-dave

/==================
www.urth.org
we await the New Sun
==================/

27

Hmmm…Well, I logged in as viewer/viewer and the intro page is quick,
but did you happen to click on “View Bugs” in either IE 5.5 or Netscape
6.2? Don’t know about Mozilla, but that style sheet takes a
realllllllllly long time to load. 15 seconds in IE and 18.777 seconds in
Netscape (as it said on the status bar).

O- ~ARK

28 
Maybe I am picky our just a lazy admin, but I believe that decent

system sould be maintainable, should be able install them in a snap,
reconfigure them, see what it is doing. You should be able to rebuild in
under one hour or less from nothing to live.

It sounds like you’re lazy. Despite what Larry Wall says, it isn’t
always a virtue.

Well I am lazy and just installed RT a couple of weeks ago. The system I
installed on was a mostly out of the box RHL 7.3. Hardware-wise an
AMD(K-6) 3D/350 MHz with 128 MByte RAM and a 8 GByte IDE drive.
Installed from the tarball and didn’t use the CPAN module. Getting all
the perl modules was … fun and time consuming but not that difficult.
So fare being lazy can work.

This is a very lightly loaded RT system so I can’t say too much about how
it will perform later but it is also the name server for several thousand
accounts/computers, runs Apache and PostgreSQL and I haven’t had any
complaints about speed. (One small snafu with a name server entry
yesterday caused it to not work at all - the guilty will remain nameless -
but I fixed that. :slight_smile:

Oh I did make the changes in httpd.conf for the number of processes
suggested a few days ago on the list.

I also just checked the system watching with top set to 1 second refresh
and saw the httpd and postmaster jump to 45%+ of the cpu for < 3 seconds
which doesn’t surprise me since they both are running stock.

I like RT.
Rod
“Open Source Software - Sometimes you get more than you paid for…”

29

Hmmm…Well, I logged in as viewer/viewer and the intro page is quick,
but did you happen to click on “View Bugs” in either IE 5.5 or Netscape
6.2? Don’t know about Mozilla, but that style sheet takes a
realllllllllly long time to load. 15 seconds in IE and 18.777 seconds in
Netscape (as it said on the status bar).

I didn’t say I LIKED Mantis. Just that I came from it. In fact, that
should be a clue right there. :slight_smile:

xoox,
Andy

‘Andy Lester andy@petdance.com
Programmer/author petdance.com
Daddy parsley.org/quinn Jk’=~/.+/s;print((split//,$&)
[unpack’C*‘,"n2]3%+>"34.’%&.‘^%4+!o.’"])

30

slightly off-topic…

I’d also big performance problems with rt2 and went back to rt1.
are there any addons/fixes for the mime-types in the subject-line
for rt1?

robert

PS: about 100 people using rt with now Serial Number: 252815

31

“Maren S. Leizaola” maren@leizaola.com writes:

The board is an ASUS P2BF-D (old but great board), with two PII 450Mhz,
the machine has 512MB of RAM, the disks are running on a promise raid
TX2-100. The disks are idle, the HTTP deamons eat CPU like there is no
tomorow, and they inflate themselves like zepplins, even with only one
user.

Use mod_fastcgi instead. Then you’ll have to cope just with one
growing process. :slight_smile:

If you use mod_perl and the httpd children die too quickly (after too
few process requests), then you incur the horrendous RT loading
overhead on every second ticket or so. This can kill your performance
much more thoroughly than any other way (with the notable exception of
an un-VACUUM-ed PostgreSQL database, of course).

Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898

32 
Maybe I am picky our just a lazy admin, but I believe that decent

system sould be maintainable, should be able install them in a snap,
reconfigure them, see what it is doing. You should be able to rebuild in
under one hour or less from nothing to live.

It sounds like you’re lazy. Despite what Larry Wall says, it isn’t
always a virtue.

Now now children, you’re starting to sound like the qmail list. Thats
the unfortunate aspect, not that someone has found RT2 not to their
liking.

Maren, its unfortunate that you’ve found RT2 to be unusable. Should you
wish to return to RT, the rt-users list can assist you provided that you
ask for assistance and provide details of the problem.

For rather lightweight ticket/problem managers, theres gnats or
{w,www}req. For medium weight, bugzilla or RT1 with a bit of spit and
polish to add the requested features (there are hints on how to do this in
rt-users about a year or more ago).

Kind regards,

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B             Operations/Security
33 
Maybe I am picky our just a lazy admin, but I believe that decent

system sould be maintainable, should be able install them in a snap,
reconfigure them, see what it is doing. You should be able to rebuild in
under one hour or less from nothing to live.

It sounds like you’re lazy. Despite what Larry Wall says, it isn’t
always a virtue.

Now now children, you’re starting to sound like the qmail list. Thats
the unfortunate aspect, not that someone has found RT2 not to their
liking.

Maren, its unfortunate that you’ve found RT2 to be unusable. Should you
wish to return to RT, the rt-users list can assist you provided that you
ask for assistance and provide details of the problem.

Right now I am thinking of engaging Jesse, the man himself, to prove me
wrong…

Let see.

For rather lightweight ticket/problem managers, theres gnats or
{w,www}req. For medium weight, bugzilla or RT1 with a bit of spit and
polish to add the requested features (there are hints on how to do this in
rt-users about a year or more ago).

I will have a quick peak.

Maren.

34

Sorry to say this (don’t want to start any flame war), but yer one hell
of a lazy admin. What the hell do they pay you for?

If you want to pull out the best of PHP, mysql, etc… There is more to
it then just simple ./configure ; make ; make install.

I admit that first i thought RT was a nightmare to set up, now I don’t
anymore…

A.From: rt-users-admin@lists.fsck.com
[mailto:rt-users-admin@lists.fsck.com] On Behalf Of Maren S. Leizaola
Sent: Tuesday, August 20, 2002 10:14 AM
To: Dave Rolsky
Cc: David C. Troy; Rt-Users (E-mail)
Subject: Re: [rt-users] RT2 Speed/performance problems.

Well I’ve optimized the tables when stuff has been deleted but other

than that I am using mysql default installation. A totally dedicated

machine.

The default mysql config uses very little memory and doesn’t take
advantage of multiple processors as well as it could. Actually tuning

MySQL can have a big impact.

I’d also recommend to anyone that they either use Mason 1.05 or
1.1201, but not 1.10 or 1.11. 1.12 is also fine except it doesn’t
work with Perl 5.00503. The 1.10 and 1.11 releases have memory leaks
that can suck up some decent memory, so up- or down-grading is
definitely recommended. If you’re not using Mason for other
development, there’s little reason to upgrade from 1.05 for those
currently using . 1.12 does offer a lot of cool new features, but it’s

also slower.

Of course, the chances that Mason was the bottleneck in Maren’s case
are very small, since RT is most likely going to be DBMS-bound once
more than a small number of tickets have been created.

Dave,
Maybe I am picky our just a lazy admin, but I believe that
decent system sould be maintainable, should be able install them in a
snap, reconfigure them, see what it is doing. You should be able to
rebuild in under one hour or less from nothing to live.

This was what I was referring to that RT2 has gone in the wrong
direction. The installation is a nightmare if you compare it to just
about any other Open source system I have had on my machines during the
past 8 years…

Look at what you have above, you have to tune, mysql, mason, the right
version, make sure that mode perl does this, make sure that apache kills
the process after etc…

I don’t doubt that you guys love it and without it you would struggle.
Well maybe it is just me. I like systems software like postfix, Nuke,
that do their job and let me get on with what I should be doing.

Cheers,
Maren.

-dave

/==================
www.urth.org
we await the New Sun
==================/

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

35

As a Non-IT person running a webserver with RT and PostNuke, I thought I’d
wade into the discussion:

First: I’m not a programmer, sys-admin, or have EVER had formal IT training.
I’m an advanced computer USER who happens to be a lab technician with an
interest in computers.

Second: I set up a webserver to support my lab users and environment. I
loaded a Dual Ultra-II (UltraSparc) with 512MB of RAM and a 4GB hard disk
with Solaris 8, manually added the packages for GNU tools, PERL 5.6.1, and
then used ApacheToolbox to help with installing Apache, MySQL, and all the
required packages. It all still required tweaking to get it all running
properly with Solaris. All of my Unix/PERL/PHP/MySQL skills are self
taught, with a lot of help from google.ca and people on mailing lists like
this one.

Third: I installed RT (and I did fight with it to get all the dependancies
working), but I thought it was worth it, because RT2 was the best that I had
seen out there, and because this list was active and people were very
helpful in doing mods and fixes.

Fourth: I modified RT2 and PostNuke to get them to do what I want them to
do. My RT pages load in 2 seconds typically, and my PostNuke pages load in
3-5. I’m still tweaking both systems as I learn new things from the people
on this list and on PostNuke.com. What I’ve learned over my years of
being a computer user is that nothing is ever perfect out-of-the-box, and
you only get out of it what you put into it. RT and PostNuke are both very
extensible, well-designed systems, and I think that you can get a lot from
those systems if you’re willing to put some time into them! My $0.02
worth… (before taxes!)

Lastly, I would like to thank all the RT-User’s Listers for all their
assistance, especially Rich Lafferty, Phil Homewood, Michael Grubb, Mike
Quitero, Smylers, Bruce Campbell and Paul Rossman (and anyone else who’s
helped me out in the past that I might have missed!)

/Mike
Lab Services
Alcatel BNDFrom: rt-users-admin@lists.fsck.com
[mailto:rt-users-admin@lists.fsck.com]On Behalf Of Maren S. Leizaola
Sent: Tuesday, August 20, 2002 3:43 AM
To: Rich Lafferty
Cc: Rt-Users (E-mail)
Subject: Re: [rt-users] RT2 Speed/performance problems.

3-10 seconds is the norm, for us it does not cut it.

So yours takes 5-10x as long as mine when I use Mozilla, but runs on
faster hardware. Still think it’s RT?

Well this is what I see…

The board is an ASUS P2BF-D (old but great board), with two PII 450Mhz,
the machine has 512MB of RAM, the disks are running on a promise raid
TX2-100. The disks are idle, the HTTP deamons eat CPU like there is no
tomorow, and they inflate themselves like zepplins, even with only one
user.

I also think that RT UI is designed for large teams and the number of
clicks at the interface are execessive for smaller support teams. Less
clicks more speed more e-mails out. With RT1 we could respond about 10% of
e-mails in under 5 mins, as it was quick and nimble.

Cheers,
Maren.

-Rich

–
Rich
Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | Save The Pacific Northwest Tree Octopus

rich@lafferty.ca -----------±----------------------------------------------

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

36

Hello!On Tue, 2002-08-20 at 08:37, Simon Cozens wrote:

Aha! It’s going to be a problem with your mod_perl configuration. We’re
seeing the same sort of thing, and after considerable profiling, I’m
convinced it’s Apache/mod_perl at fault.

At a guess, you’re running on old version of Perl or mod_perl which
doesn’t have the advantage of Doug McEachern’s wonderful recent work on
sharable variables or his many memory leak fixes.

Could you elaborate? I’m curious if this may relate to some residual
slowness on our site.

Thanks!

–j
Jim Meyer, Geek At Large purp@wildbrain.com

37

So why aren’t you using RT1?

No support for MIME attachments

Installed stripmime, hacked at it for a few hours to obtain
links to the attachments inline (not quite perfect solution but
good enough).

not being able to display chinese Big5/GB Code e-mail.

Doesn’t sound too difficult; wouldn’t it be just attaching a
content-type header in appropriate cases?

My only beef with RT1 speed is plaintext search over the whole
database, but I’ll be eliminating the need for the search soon,
so I won’t have to think about interfacing with an external
indexing search engine.

#include <std_disclaim.h> Lorens Kockum

38

not being able to display chinese Big5/GB Code e-mail.
Doesn’t sound too difficult; wouldn’t it be just attaching a
content-type header in appropriate cases?

I have been hacking Big5 RT for quite a while; the trick is
simply go get perl 5.8, apply Encode::Guess (or if you’re sure
about the encoding, just using the appropriate encoding),
and do a Encode::decode() on each chunk of email.

If you want to be fancy, you could even

binmode ':encoding(big5)', $mailfh;

My only beef with RT1 speed is plaintext search over the whole
database, but I’ll be eliminating the need for the search soon,
so I won’t have to think about interfacing with an external
indexing search engine.

We’re also planning to hook RT with a Chinese-aware search engine
(OurNet::FuzzyIndex); the process looks straightforward.

Thanks,
/Autrijus/