When an owner is "out of office"

RT Users
1

Hi everyone,

Hopefully someone has put some brain into this before and can suggest how to solve it.

Has anyone found an efficient way of dealing with owners being on leave/away for extended periods. I want to avoid tickets just lying there for a week or two and the requestor wondering what’s going on.

One way would be for the owner to reply to each ticket to send a message to the requester that he will be away for some time. Another way would be to somehow set the owner’s profile as away, but that would involve database changes, thus possibly deviating too far of the standard RT.

How do you address this problem? Add ticket watchers, maybe. Queue watchers would probably be more appropriate, but that person will be swamped with the masses of mail to check. Has anyone made helpful changes to RT that could help solve this?

Regards,

Rehan van der Merwe
Neil Harvey & Associates (Pty) Ltd
http://www.nha.co.za
rehan@nha.co.za
Tel: +27 21 9504424
Fax: +27 21 9505424

2

My apologies - this query falls pretty much in line with Nathan Evans’s “Vacation reassignment” - I missed that when I browsed the list.

Rehan-----Original Message-----
From: Rehan van der Merwe
Sent: Tuesday, August 20, 2002 12:35 PM
To: Rt-Users (E-mail)
Subject: [rt-users] When an owner is “out of office”

Hi everyone,

Hopefully someone has put some brain into this before and can suggest how to solve it.

Has anyone found an efficient way of dealing with owners being on leave/away for extended periods. I want to avoid tickets just lying there for a week or two and the requestor wondering what’s going on.

One way would be for the owner to reply to each ticket to send a message to the requester that he will be away for some time. Another way would be to somehow set the owner’s profile as away, but that would involve database changes, thus possibly deviating too far of the standard RT.

How do you address this problem? Add ticket watchers, maybe. Queue watchers would probably be more appropriate, but that person will be swamped with the masses of mail to check. Has anyone made helpful changes to RT that could help solve this?

Regards,

Rehan van der Merwe
Neil Harvey & Associates (Pty) Ltd
http://www.nha.co.za
rehan@nha.co.za
Tel: +27 21 9504424
Fax: +27 21 9505424

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

3

Dear All,
Much regretably I’ve had to pull RT2 out. 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. As
it was costing us more on having to wait for the pages to refresh and do
maintenance on it than the time required of handlign all e-mail manually.
I think we are now in a much better position with our e-mail support
without using RT than with RT.

I know it easy to come into a mailing list and piss over someone elses
hard work, however I feel that RT is going has been going in the wrong
direction. Anyway I think the Jesse and everyone else is well aware of
this issue so why go on. Well do for what you have done even though it
is not very strong in the performance area.

I would really like to find some “light” ticketing system where the front
end is PHP based where deamons do not eat up 62MB of RAM or more… I
don’t need all the fancy stuff that RT2 has. A spec like RT1, with
atachments and being able to display chinese characters would be all we
need.

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

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

Maren.

4

Maren,

You’re on crack. I’ve got a system with about 50,000 tickets in it and
it runs very fast.

If you knew anything about the code, you’d know the bulk of the speed
issues derive from the backend database, not RT itself. Perhaps you are
having issues there, or your database is not optimized.

Not to flame you, but that msg is the most ignorant comment about a piece
of software I’ve seen in ages.

Admittedly, there are ways RT and the database backend could be
accelerated, but discuss those with knowledge of how algorithms and
systems actually work. Look at the code, ask questions, and offer
suggestions, but don’t complain about it.

Throwing hardware at the problem was probably your first mistake. If a 2
CPU, RAID, 512MB system is ‘slow’ then you’ve got serious problems. If
you had bothered to ask the list, you’d know that RT2 can run just fine on
plain old single CPU/IDE systems. I use a PIII 700 with IDE and over
50,000 tickets and 30 users and it works great.

I’m sorry, but it’s people like you who give IT professionals a bad name.
Go to school or read a book and learn something about your profession.
Til then, you’d probably be better off lurking humbly on maillists such as
these than displaying your ignorance with such panache.

Dave

David C. Troy [dave@toad.net] 410-544-6193 Sales
ToadNet - Want to go fast? 410-544-1329 FAX
570 Ritchie Highway, Severna Park, MD 21146-2925 www.toad.netOn Tue, 20 Aug 2002, Maren S. Leizaola wrote:

Dear All,
Much regretably I’ve had to pull RT2 out. 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. As
it was costing us more on having to wait for the pages to refresh and do
maintenance on it than the time required of handlign all e-mail manually.
I think we are now in a much better position with our e-mail support
without using RT than with RT.

I know it easy to come into a mailing list and piss over someone elses
hard work, however I feel that RT is going has been going in the wrong
direction. Anyway I think the Jesse and everyone else is well aware of
this issue so why go on. Well do for what you have done even though it
is not very strong in the performance area.

I would really like to find some “light” ticketing system where the front
end is PHP based where deamons do not eat up 62MB of RAM or more… I
don’t need all the fancy stuff that RT2 has. A spec like RT1, with
atachments and being able to display chinese characters would be all we
need.

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

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

Maren.

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

5

Dear All,
Much regretably I’ve had to pull RT2 out. 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.

We’ve got a much smaller machine than that, with a similar number of
tickets, and response times in lynx (to get rid of rendering time) is
less than a second. It Ain’t RT, and I doubt you’ll find anything
sufficiently light to solve your actual problem, whatever it might be.

-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 -----------±----------------------------------------------

6

Maren S. Leizaola writes:

Much regretably I’ve had to pull RT2 out. 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. As
it was costing us more on having to wait for the pages to refresh and do
maintenance on it than the time required of handlign all e-mail manually.
I think we are now in a much better position with our e-mail support
without using RT than with RT.

I’m not sure, but it sounds like a configuration error. I’m running an RT
instance with ~12000 tickets on a FreeBSD system with one Pentium II 330MHz
processor and about 400MB of memory. The mysql database is running on the
same system, and I’m not having any serious performance problems. Takes
about 3 seconds to pull up the home page, and about 8 seconds to bring up
the main display page for an average ticket. We could improve things a
bit by using slightly less junk hardware, but it’s been sufficient for now.

Can’t help you with alternate ticketing systems, since all the other ones I
tried weren’t usable.
-Matt

Matthew D. Stock stock@cse.buffalo.edu
Director of Information Technology
Computer Science and Engineering, University at Buffalo

7

Maren,

You’re on crack. I’ve got a system with about 50,000 tickets in it and
it runs very fast.

I am glad for you, but I’ve not had the same experience…

If you knew anything about the code, you’d know the bulk of the speed
issues derive from the backend database, not RT itself. Perhaps you are
having issues there, or your database is not optimized.

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.

Not to flame you, but that msg is the most ignorant comment about a piece
of software I’ve seen in ages.

You are entitled to your opinion. However isn’t it ignorant not to accept
that other people could be having and experience different to
yours using RT2?

Admittedly, there are ways RT and the database backend could be
accelerated, but discuss those with knowledge of how algorithms and
systems actually work. Look at the code, ask questions, and offer
suggestions, but don’t complain about it.

Well I shared my view I am off this list, I just want to know if anyone
can recommend something small and light, that’s all, ideally PHP based.

Throwing hardware at the problem was probably your first mistake. If a 2
CPU, RAID, 512MB system is ‘slow’ then you’ve got serious problems. If
you had bothered to ask the list, you’d know that RT2 can run just fine on
plain old single CPU/IDE systems. I use a PIII 700 with IDE and over
50,000 tickets and 30 users and it works great.

Well that is good for you. I do know of a company that has hired Jesse to
customise RT for their requirements and they also told me it is a complete
pig. As for throwing hardware at the problem, that is the hardware I had
but obviously one has to go with slower hardware to go faster?

I’m sorry, but it’s people like you who give IT professionals a bad name.
Go to school or read a book and learn something about your profession.
Til then, you’d probably be better off lurking humbly on maillists such as
these than displaying your ignorance with such panache.

Sure. Anyway one less ignorant twerp using RT2 right?

Maren.

8

Maren S. Leizaola writes:

Much regretably I’ve had to pull RT2 out. 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. As
it was costing us more on having to wait for the pages to refresh and do
maintenance on it than the time required of handlign all e-mail manually.
I think we are now in a much better position with our e-mail support
without using RT than with RT.

I’m not sure, but it sounds like a configuration error. I’m running an RT
instance with ~12000 tickets on a FreeBSD system with one Pentium II 330MHz
processor and about 400MB of memory. The mysql database is running on the
same system, and I’m not having any serious performance problems. Takes
about 3 seconds to pull up the home page, and about 8 seconds to bring up
the main display page for an average ticket. We could improve things a
bit by using slightly less junk hardware, but it’s been sufficient for now.

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

Can’t help you with alternate ticketing systems, since all the other ones I
tried weren’t usable.

Ok thanks.
Maren.

9

I am new to RT… Only been using it since June, but my system is running
fine… it is a Celeron 1GHz with 256MB ram and mysql backend. My number of
tickets is relatively small but it is still very fast.

I guess the reason I am posting this is so that Maren’s message doesn’t
discourage new users from using RT. It’s a great solution to call tracking
on a budget!

James Harrison-----Original Message-----
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 1:37 AM
To: Rt-Users (E-mail)
Subject: [rt-users] RT2 Speed/performance problems.

Dear All,
Much regretably I’ve had to pull RT2 out. 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. As
it was costing us more on having to wait for the pages to refresh and do
maintenance on it than the time required of handlign all e-mail manually.
I think we are now in a much better position with our e-mail support
without using RT than with RT.

I know it easy to come into a mailing list and piss over someone elses
hard work, however I feel that RT is going has been going in the wrong
direction. Anyway I think the Jesse and everyone else is well aware of
this issue so why go on. Well do for what you have done even though it
is not very strong in the performance area.

I would really like to find some “light” ticketing system where the front
end is PHP based where deamons do not eat up 62MB of RAM or more… I
don’t need all the fancy stuff that RT2 has. A spec like RT1, with
atachments and being able to display chinese characters would be all we
need.

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

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

Maren.

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

10

Not to flame you, but that msg is the most ignorant comment about a piece
of software I’ve seen in ages.

You are entitled to your opinion. However isn’t it ignorant not to accept
that other people could be having and experience different to
yours using RT2?

I accept that completely. If you wanted help fixing it, I’d even offer
some suggestions on how to bring your experience into line with the way
the software works when it’s properly configured.

Well I shared my view I am off this list, I just want to know if anyone
can recommend something small and light, that’s all, ideally PHP based.

So you can enjoy all the dumb bugs in PHP as opposed to the dumb bugs in
mod_perl. :slight_smile: The file_upload thing in 4.0.6 is a good one…

Well that is good for you. I do know of a company that has hired Jesse to
customise RT for their requirements and they also told me it is a complete
pig. As for throwing hardware at the problem, that is the hardware I had
but obviously one has to go with slower hardware to go faster?

RT may have some areas where performance could be improved based on its
reliance on mod_perl and Mason, but these dependencies don’t render the
software unusable and are not the limiting factors for performance.
Decent, well tuned software doesn’t require fat hardware to work well, and
RT falls within this envelope.

When you say things like ‘RT is a complete pig’, what do you mean,
exactly? MySQL is a pig? Apache is a pig? Perl is a pig? mod_perl is a
pig? Mason is a pig? PostgreSQL is a pig?

Again, there are always ways software can be improved, but what I’m
telling you is that your experience is way outside of the bell curve for
the software/hardware you’re talking about, and that you should probably
investigate that.

Dave

David C. Troy [dave@toad.net] 410-544-6193 Sales
ToadNet - Want to go fast? 410-544-1329 FAX
570 Ritchie Highway, Severna Park, MD 21146-2925 www.toad.net

11

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?

-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 -----------±----------------------------------------------

12

Maren S. Leizaola:

Much regretably I’ve had to pull RT2 out. 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. As
it was costing us more on having to wait for the pages to refresh and do
maintenance on it than the time required of handlign all e-mail manually.
I think we are now in a much better position with our e-mail support
without using RT than with RT.

Did you benchmark it? Did you profile it? Where were the bottlenecks for
you?

Did you see problems with the command-line interface as well as the web
interface? Was the backend fast enough? How long was it taking for mail
to be processed through the mail gateway?

Were you running Postgres or MySQL? Were your indexes working OK? Was
the database being vacuumed/analysed regularly? Was raw SQL access fast
enough?

Did you add ?Debug=1 to a URL to determine whether or not it was an RT
problem or a browser rendering problem? (That surprised a few of our
users.) Were the machines you were running the browsers on OK? Were you
using sane browsers?

Was the Mason cache being populated properly? Did you tune your Apache
config? Did you use Apache::Status?

end is PHP based where deamons do not eat up 62MB of RAM or more… I

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.

Other people have seen RT running incredibly quickly on less powerful
machines, so I’m not going to dismiss it as a problem at RT’s end; I
think it’s a problem with the way we’ve set it up.

Simon

I often think I’d get better throughput yelling at the modem.

13

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.

14

Apache/mod_perl is often a culprit, well, mostly mod_perl, I think. Make
sure you have Apache processes set to die after a certain number of
requests. If you set the number to 0, they won’t die, and it’ll just bog
down. Our installation used to run relatively quickly at first, but as
those processes lived on, the machine slowed to a crawl; changing this
setting fixed this gradual slowdown. Not sure if this is in the docs,
but it should be…

O- ~ARK

15

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

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

16

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.

If you really don’t care about solving your problem, you should seek
another solution. But it really does sound like you have a problem with
your version of Apache/mod_perl that’s causing this. That hardware should
not have a problem.

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.

This is a non-issue. I can process 20 tickets assigned to me with three
clicks per ticket (one to view it, one to reply, one to save the
response), and no perceivable delays between clicks. If you have it setup
some other way then you have it configured wrong.

Dave

David C. Troy [dave@toad.net] 410-544-6193 Sales
ToadNet - Want to go fast? 410-544-1329 FAX
570 Ritchie Highway, Severna Park, MD 21146-2925 www.toad.net

17

Maren S. Leizaola:

end is PHP based where deamons do not eat up 62MB of RAM or more… I

Aha! It’s going to be a problem with your mod_perl configuration.

Aha indeed. I’m using FastCGI here. Strongly recommended.

-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 -----------±----------------------------------------------

18

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.

19

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.

I think you should be able to build a car out of popsicle sticks, too, but
it’d probably be a pretty crappy car. Sometimes things require complex
moving parts.

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…

That’s just not the case. Anything that requires a backend database has
some complexity. If you thought RT was fun, try getting MySQL support
going with Cyrus-SASL, Postfix, Sendmail, Freeradius, IMAP, etc… these
things are hard and sometimes require writing code. RT is nowhere near
that complicated.

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…

Again this is no more or less than any other complex software…

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.

It’s not about ‘loving RT’. Write a version of RT that uses PHP+Postfix
and installs with an easy installation script and I’m sure many of us will
switch to it. Right now RT’s the best thing going, and it’s pretty
average when it comes to complexity, considering that it has a web
interface, a powerful mail interface, a CLI, and a backend database.

Dave

David C. Troy [dave@toad.net] 410-544-6193 Sales
ToadNet - Want to go fast? 410-544-1329 FAX
570 Ritchie Highway, Severna Park, MD 21146-2925 www.toad.net

20

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”.

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?

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.’"])