Performance problems

Hi!

I installed Request Tracker (2.0.1). Everything works correct, but the
performance of the web interface is very poor. I’ve to wait four
seconds for every page.

I’m not sure whether this issue is caused by RT2 itself, or by a Perl
module or the MySQL database. Maybe somebody out there can help me.

Here is what ‘make testdeps’ says:

Checking for DBI 1.16 …found
Checking for DBIx::DataSource 0.02 …found
Checking for DBIx::SearchBuilder 0.40 …found
Checking for HTML::Entities…found
Checking for MLDBM…found
Checking for Net::Domain…found
Checking for Net::SMTP…found
Checking for Params::Validate 0.02 …found
Checking for HTML::Mason 0.896 …found
Checking for CGI::Cookie 1.06 …found
Checking for Apache::Session 1.53 …found
Checking for Date::Parse…found
Checking for Date::Format…found
Checking for MIME::Entity 5.108 …found
Checking for Mail::Mailer 1.20 …found
Checking for Getopt::Long 2.24 …found
Checking for Tie::IxHash…found
Checking for Text::Wrapper…found
Checking for Text::Template…found
Checking for File::Spec 0.8 …found
Checking for Errno…found
Checking for File::Temp…found
Checking for Log::Dispatch 1.6 …found
Checking for DBD::mysql 2.0416 …found

I’m using Apache 1.3.20, MySQL 3.23.32 and mod_perl 1.26.

And here’s what I have in httpd.conf (inside VirtualHost).

Alias /rt2/ “/usr/local/rt2/WebRT/html/”
<Location “/rt2”>
PerlModule Apache::DBI
PerlRequire “/usr/local/rt2/bin/webmux.pl”
SetHandler perl-script
PerlHandler RT::Mason

Btw, I’m using MySQL very intensively, so it should work fine.

Thanks,
Manuel

Manuel Linsmayer manuel.linsmayer@expersite.com
Fingerprint BDA6 8884 A5F3 D8D7 5D77 C183 13F8 5E16 357E 36FD

What kind of hardware are you running?

My first successful install of WebRT2 was on an old machine, P233 with 64MB
RAM. It performed very badly – about 5-10 seconds per page. I’m now
running it on a production system which has a P3-900, 256MB RAM and it takes
microseconds to generate a page.

Hope this helps…

Trevor Sky Garside
trevor@trevorsky.com----- Original Message -----
From: “Manuel Linsmayer” manuel.linsmayer@expersite.com
To: rt-users@lists.fsck.com
Sent: Saturday, July 14, 2001 4:34 PM
Subject: [rt-users] Performance problems

Hi!

I installed Request Tracker (2.0.1). Everything works correct, but the
performance of the web interface is very poor. I’ve to wait four
seconds for every page.

I’m not sure whether this issue is caused by RT2 itself, or by a Perl
module or the MySQL database. Maybe somebody out there can help me.

Here is what ‘make testdeps’ says:

Checking for DBI 1.16 …found
Checking for DBIx::DataSource 0.02 …found
Checking for DBIx::SearchBuilder 0.40 …found
Checking for HTML::Entities…found
Checking for MLDBM…found
Checking for Net::Domain…found
Checking for Net::SMTP…found
Checking for Params::Validate 0.02 …found
Checking for HTML::Mason 0.896 …found
Checking for CGI::Cookie 1.06 …found
Checking for Apache::Session 1.53 …found
Checking for Date::Parse…found
Checking for Date::Format…found
Checking for MIME::Entity 5.108 …found
Checking for Mail::Mailer 1.20 …found
Checking for Getopt::Long 2.24 …found
Checking for Tie::IxHash…found
Checking for Text::Wrapper…found
Checking for Text::Template…found
Checking for File::Spec 0.8 …found
Checking for Errno…found
Checking for File::Temp…found
Checking for Log::Dispatch 1.6 …found
Checking for DBD::mysql 2.0416 …found

I’m using Apache 1.3.20, MySQL 3.23.32 and mod_perl 1.26.

And here’s what I have in httpd.conf (inside VirtualHost).

Alias /rt2/ “/usr/local/rt2/WebRT/html/”
<Location “/rt2”>
PerlModule Apache::DBI
PerlRequire “/usr/local/rt2/bin/webmux.pl”
SetHandler perl-script
PerlHandler RT::Mason

Btw, I’m using MySQL very intensively, so it should work fine.

Thanks,
Manuel


Manuel Linsmayer manuel.linsmayer@expersite.com
Fingerprint BDA6 8884 A5F3 D8D7 5D77 C183 13F8 5E16 357E 36FD


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

What kind of hardware are you running?

400 MHz CPU with 64 MB RAM.

I can’t believe that this isn’t enough for RT2. Four seconds to process
a request is not acceptable, not even on that old hardware.

Manuel

Manuel Linsmayer manuel.linsmayer@expersite.com
Fingerprint BDA6 8884 A5F3 D8D7 5D77 C183 13F8 5E16 357E 36FD

I’d look first to the amount of ram you have in that box. Assuming
Unix/Linux, run top or it’s equivalent and see how much swap your system is
using. If it’s using any swap consistently, then you need more ram.

Also look at the load numbers provided by top. If they are over 1, then you
need a better hardware. More memory should help, but a faster processor
might be in order as well.

At 02:12 AM 7/15/2001 +0200, Manuel Linsmayer wrote:

What kind of hardware are you running?

400 MHz CPU with 64 MB RAM.

I can’t believe that this isn’t enough for RT2. Four seconds to process
a request is not acceptable, not even on that old hardware.

Russ Johnson
Stargate Online

http://www.dimstar.net
telnet://telnet.dimstar.net
ICQ: 3739685

The browser can also be a factor.
Some information from here:
WinMe running ie5.5 with Nortons Personal Privacy (web ad stripping,
cookie handling) takes about 4-5 seconds.
Netscape on Mandrake takes about the same.
Lynx on Redhat almost instantanious.-----Original Message-----
From: rt-users-admin@lists.fsck.com
[mailto:rt-users-admin@lists.fsck.com] On Behalf Of Manuel Linsmayer
Sent: Saturday, July 14, 2001 7:35 PM
To: rt-users@lists.fsck.com
Subject: [rt-users] Performance problems

Hi!

I installed Request Tracker (2.0.1). Everything works correct, but the
performance of the web interface is very poor. I’ve to wait four
seconds for every page.

I’m not sure whether this issue is caused by RT2 itself, or by a Perl
module or the MySQL database. Maybe somebody out there can help me.

Here is what ‘make testdeps’ says:

Checking for DBI 1.16 …found
Checking for DBIx::DataSource 0.02 …found
Checking for DBIx::SearchBuilder 0.40 …found
Checking for HTML::Entities…found
Checking for MLDBM…found
Checking for Net::Domain…found
Checking for Net::SMTP…found
Checking for Params::Validate 0.02 …found
Checking for HTML::Mason 0.896 …found
Checking for CGI::Cookie 1.06 …found
Checking for Apache::Session 1.53 …found
Checking for Date::Parse…found
Checking for Date::Format…found
Checking for MIME::Entity 5.108 …found
Checking for Mail::Mailer 1.20 …found
Checking for Getopt::Long 2.24 …found
Checking for Tie::IxHash…found
Checking for Text::Wrapper…found
Checking for Text::Template…found
Checking for File::Spec 0.8 …found
Checking for Errno…found
Checking for File::Temp…found
Checking for Log::Dispatch 1.6 …found
Checking for DBD::mysql 2.0416 …found

I’m using Apache 1.3.20, MySQL 3.23.32 and mod_perl 1.26.

And here’s what I have in httpd.conf (inside VirtualHost).

Alias /rt2/ “/usr/local/rt2/WebRT/html/”
<Location “/rt2”>
PerlModule Apache::DBI
PerlRequire “/usr/local/rt2/bin/webmux.pl”
SetHandler perl-script
PerlHandler RT::Mason

Btw, I’m using MySQL very intensively, so it should work fine.

Thanks,
Manuel

Manuel Linsmayer manuel.linsmayer@expersite.com
Fingerprint BDA6 8884 A5F3 D8D7 5D77 C183 13F8 5E16 357E 36FD

rt-users mailing list
rt-users@lists.fsck.com http://lists.fsck.com/mailman/listinfo/rt-users

Well, my take on it is that RT2 is designed to be capable of a heavy load,
and so it makes use of mod_perl, and Mason, which appear to be somewhat of
resource hogs. I would bet that the problem is exclusively the RAM, because
on my P233/64MB I noticed the hard drive chunking away the whole time it was
processing the request, meaning my poor Red Hat system was killing itself on
the swap partition. Have a quick check of pricewatch.com and you’ll see
that using a bit of RAM is probably the best of any resource to waste – RAM
is insanely cheap these days.

But this does lead to a good question for the developer: is there any
(easy) way to knock down the system requirements on this product? It would
be nice to toss an old system from the closet in as a ticket server, this
way I don’t have to piggy-back it onto a machine already tasked with other
functions (which I hate doing because of paranoia about security).

Trevor Sky Garside
trevor@trevorsky.com----- Original Message -----
From: “Manuel Linsmayer” manuel.linsmayer@expersite.com
To: rt-users@lists.fsck.com
Sent: Saturday, July 14, 2001 5:12 PM
Subject: Re: [rt-users] Performance problems

What kind of hardware are you running?

400 MHz CPU with 64 MB RAM.

I can’t believe that this isn’t enough for RT2. Four seconds to process
a request is not acceptable, not even on that old hardware.

Manuel


Manuel Linsmayer manuel.linsmayer@expersite.com
Fingerprint BDA6 8884 A5F3 D8D7 5D77 C183 13F8 5E16 357E 36FD


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Netwscape 4.x’s layout engine chokes badly on nested tables. IE 4.x and 5.x,
mozilla, lynx, links and w3m all perform much better than netscape 4.On Sat, Jul 14, 2001 at 08:18:35PM -0400, Stephen Feather wrote:

The browser can also be a factor.
Some information from here:
WinMe running ie5.5 with Nortons Personal Privacy (web ad stripping,
cookie handling) takes about 4-5 seconds.
Netscape on Mandrake takes about the same.
Lynx on Redhat almost instantanious.

-----Original Message-----
From: rt-users-admin@lists.fsck.com
[mailto:rt-users-admin@lists.fsck.com] On Behalf Of Manuel Linsmayer
Sent: Saturday, July 14, 2001 7:35 PM
To: rt-users@lists.fsck.com
Subject: [rt-users] Performance problems

Hi!

I installed Request Tracker (2.0.1). Everything works correct, but the
performance of the web interface is very poor. I’ve to wait four
seconds for every page.

I’m not sure whether this issue is caused by RT2 itself, or by a Perl
module or the MySQL database. Maybe somebody out there can help me.

Here is what ‘make testdeps’ says:

Checking for DBI 1.16 …found
Checking for DBIx::DataSource 0.02 …found
Checking for DBIx::SearchBuilder 0.40 …found
Checking for HTML::Entities…found
Checking for MLDBM…found
Checking for Net::Domain…found
Checking for Net::SMTP…found
Checking for Params::Validate 0.02 …found
Checking for HTML::Mason 0.896 …found
Checking for CGI::Cookie 1.06 …found
Checking for Apache::Session 1.53 …found
Checking for Date::Parse…found
Checking for Date::Format…found
Checking for MIME::Entity 5.108 …found
Checking for Mail::Mailer 1.20 …found
Checking for Getopt::Long 2.24 …found
Checking for Tie::IxHash…found
Checking for Text::Wrapper…found
Checking for Text::Template…found
Checking for File::Spec 0.8 …found
Checking for Errno…found
Checking for File::Temp…found
Checking for Log::Dispatch 1.6 …found
Checking for DBD::mysql 2.0416 …found

I’m using Apache 1.3.20, MySQL 3.23.32 and mod_perl 1.26.

And here’s what I have in httpd.conf (inside VirtualHost).

Alias /rt2/ “/usr/local/rt2/WebRT/html/”
<Location “/rt2”>
PerlModule Apache::DBI
PerlRequire “/usr/local/rt2/bin/webmux.pl”
SetHandler perl-script
PerlHandler RT::Mason

Btw, I’m using MySQL very intensively, so it should work fine.

Thanks,
Manuel


Manuel Linsmayer manuel.linsmayer@expersite.com
Fingerprint BDA6 8884 A5F3 D8D7 5D77 C183 13F8 5E16 357E 36FD


rt-users mailing list
rt-users@lists.fsck.com http://lists.fsck.com/mailman/listinfo/rt-users


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

jesse reed vincent – root@eruditorum.orgjesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90

A REAL sysadmin challenge is “resurrect five dead mailserver while so ripped
to the gills on mdma that you can’t focus on any given line of text for more
than 10 seconds continuously.”
-Nathan Mehl

To give you an idea of what I use RT on:

    anna.fsck.com is my laptop. It is a celeron 233 with 128 megs of ram.
    
    I run X, Xemacs, mysql, apache with mod_perl and RT on it. I _develop_
    RT on it. It performs just fine. 

    pallas.eruditorum.org is the server that serves http://fsck.com
    It is a P2/400 with 256mb of ram. It is running two rt2 instances,
    mysql, two _other_ instances of apache with mod_perl, postfix,
    bind, kerberos. zephyr, ftpd and a host of user processes. It 
    barely breaks a sweat.

    The new fastcgi handler is certainly less memory intensive than
    the mod_perl handler, but, well, RT is written in perl.

     128 more megs of ram will cost you on the order of
     $10 [1] these days. I suspect that's probably the easiest
     way to deal with your problem.  You might also want to look
     at making sure apache isn't starting more processes than it needs
     to and that other things aren't gobbling ram on the box.


     -j

[1] http://www.rich-pacific.com/1216pc168pin.html
That’s not an endorsement for rich-pacific. they were just the first
hit on pricewatch.On Sun, Jul 15, 2001 at 02:12:47AM +0200, Manuel Linsmayer wrote:

What kind of hardware are you running?

400 MHz CPU with 64 MB RAM.

I can’t believe that this isn’t enough for RT2. Four seconds to process
a request is not acceptable, not even on that old hardware.

Manuel


Manuel Linsmayer manuel.linsmayer@expersite.com
Fingerprint BDA6 8884 A5F3 D8D7 5D77 C183 13F8 5E16 357E 36FD


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

jesse reed vincent – root@eruditorum.orgjesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90

‘“As the company that brought users the Internet, Netscape is now inviting
the more than 60 million people who have used our client software to
‘tune up’ and upgrade to Netscape Communicator,” said Mike Homer,
senior vice president of marketing at Netscape.’ Sometimes I wonder.

But this does lead to a good question for the developer: is there any
(easy) way to knock down the system requirements on this product? It would
be nice to toss an old system from the closet in as a ticket server, this
way I don’t have to piggy-back it onto a machine already tasked with other
functions (which I hate doing because of paranoia about security).

Give the new fastcgi hander in 2.0.1 a shot. It should be a bit less of a
memory hog, as there’s no mod_perl overhead.

There’s always more optimization to be done. At this point, RT performs
adequately well for reasonable ticket loads on modern hardware. If a client
wanted me to spend time working on optimisation, it’s certianly something I can
do. I suspect, however, that optimizing for the low end is really a waste of
time and money, given that you could buy a new machine for far less than it
would cost for me to implement worthwhile space-saving optimisations.

    -j

Trevor Sky Garside
trevor@trevorsky.com

----- Original Message -----
From: “Manuel Linsmayer” manuel.linsmayer@expersite.com
To: rt-users@lists.fsck.com
Sent: Saturday, July 14, 2001 5:12 PM
Subject: Re: [rt-users] Performance problems

What kind of hardware are you running?

400 MHz CPU with 64 MB RAM.

I can’t believe that this isn’t enough for RT2. Four seconds to process
a request is not acceptable, not even on that old hardware.

Manuel


Manuel Linsmayer manuel.linsmayer@expersite.com
Fingerprint BDA6 8884 A5F3 D8D7 5D77 C183 13F8 5E16 357E 36FD


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

jesse reed vincent – root@eruditorum.orgjesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90

“It’s buried in the desert, got sand in it, melts Nazis. You know,
the Ark of the Covenant” – siva

“TSG” == Trevor Sky Garside trevor@trevorsky.com writes:

TSG> But this does lead to a good question for the developer: is there
TSG> any (easy) way to knock down the system requirements on this
TSG> product? It would be nice to toss an old system from the closet

The general mod_perl tuning docs (which come with mod_perl) should be
of help (if not, let me know and I shall revise them.) In particular,
if your system gets a lot of web page hits, you’ll want to put a
buffer in front of it (reverse proxy is the curren term for this.)
This will let the buffer program speak to the heavy mod_perl
application server, and then trickle the data out to the remote site
at 28.8kbps, leaving the mod_perl app server to answer another
request.

Also, you absolutely don’t want the mod_perl heavy server handling
images or any other simple static content if you can avoid it.
Depedning on the buffering program you use, this may be manually
configured, or dynamic. The mod_perl guide also has many tips on this
topic.

If you’re not using mod_perl for anything else on your web server,
think about splitting off the RT web server to its own instance on
another IP address or another port. This will minimize its impact on
your regular web server.

Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/

Jesse wrote:

Netwscape 4.x’s layout engine chokes badly on nested tables. IE 4.x and 5.x,
mozilla, lynx, links and w3m all perform much better than netscape 4.

I am seeing the same poor performance – my client machine is a 300MHZ
Ultra 10 with 256MB RAM running Solaris 8 – my ticket/database machine
is a dedicated Ultra 60 (450MHz) with 512MB RAM. I am using netscape 4
and have seen similar performance problems with netscape when big or
lots of tables are involved. Netscape 6 (mozilla?) doesn’t seem to be
much better, at least on Solaris.

-Eric

All,

We are having performance problems with RT. I have two separate RT systems. A production server running RT 3.0.9, mysql 3.23.58, perl 5.8.0, apache 1.3.29 and a test server running RT 3.0.10, mysql 4.0.18 and perl 5.8.4, apache 1.3.29. Both show the same problem.

When I start go to the RT help ticket site, I have no problem. Searching and looking at tickets are no problem. We start to have problems when either creating new tickets or modifying tickets. It might take up to a minute before the new ticket is created.

Has anyone run into this before? Is it a mysql problem? Apache problem?

Any help would be great.

Thanks,
Bruce

This E-mail is confidential. It should not be read, copied, disclosed or used by any person other than the intended recipient. Unauthorized use, disclosure or copying by whatever medium is strictly prohibited and may be unlawful. If you have received this E-mail in error, please contact the sender immediately and delete the E-mail from your system.

Kogami, Bruce wrote:

We are having performance problems with RT. I have two separate RT
systems. A production server running RT 3.0.9, mysql 3.23.58, perl 5.8.0,
apache 1.3.29 and a test server running RT 3.0.10, mysql 4.0.18 and perl
5.8.4, apache 1.3.29. Both show the same problem.

well, mysql 3.23 is not likely to be helping performance on that
instance, at any rate (and perl 5.8.0 has other crippling bugs)…
but still, your 3.0.10 instance looks sane.

When I start go to the RT help ticket site, I have no problem. Searching
and looking at tickets are no problem. We start to have problems when
either creating new tickets or modifying tickets. It might take up to
a minute before the new ticket is created.

Could it be related to RT waiting for sendmail (or equivalent)
to do a synchronous delivery of a scrip’ed notification?

Good catch. When I stopped auto-reply to New messages, it went from 45 second delay to 2 seconds.

Now, my follow-up question…
We would like to keep auto-reply on new messages. What can I do to fix sendmail so that the RT does not have to wait so long?

Thanks,
Bruce

-----Original Message-----
From: pdh@bestpractical.com [mailto:pdh@bestpractical.com]
Sent: Thursday, May 13, 2004 3:45 AM
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Performance problems

Kogami, Bruce wrote:

We are having performance problems with RT. I have two separate RT
systems. A production server running RT 3.0.9, mysql 3.23.58, perl
5.8.0,
apache 1.3.29 and a test server running RT 3.0.10, mysql 4.0.18 and perl
5.8.4, apache 1.3.29. Both show the same problem.

well, mysql 3.23 is not likely to be helping performance on that
instance, at any rate (and perl 5.8.0 has other crippling bugs)…
but still, your 3.0.10 instance looks sane.

When I start go to the RT help ticket site, I have no problem. Searching
and looking at tickets are no problem. We start to have problems when
either creating new tickets or modifying tickets. It might take up to
a minute before the new ticket is created.

Could it be related to RT waiting for sendmail (or equivalent)
to do a synchronous delivery of a scrip’ed notification?


The rt-users Archives

RT Developer and Administrator training is coming to LA, DC and Frankfurt
this spring and summer.
http://bestpractical.com/services/training.html

Sign up early, as class space is limited.

This E-mail is confidential. It should not be read, copied, disclosed or used by any person other than the intended recipient. Unauthorized use, disclosure or copying by whatever medium is strictly prohibited and may be unlawful. If you have received this E-mail in error, please contact the sender immediately and delete the E-mail from your system.