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).
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.
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).
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.
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).
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).
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.
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).
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
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.
‘“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.
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.
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.
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.
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?
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?
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.