[rt-devel] Performance (was: Kill spam from mail)]

[ivan]

RT's dismal performance comes mostly from redundant database queries.  ACL
checks are particularly bad.  The same records will be queried from the
database sometimes hundreds of times.

In my usage, there were a couple sorely missing indices, also, not sure if
those have been fixed in the official tree or not. 

If you want to hack on RT to tune it, I suggest using something like this
for webrt/Elements/Footer: 

  % if ( $DBIx::SearchBuilder::Handle::DBIHandle->can('sprintProfile') ) {
  <PRE><% $DBIx::SearchBuilder::Handle::DBIHandle->sprintProfile() |h %></PRE>
  % $DBIx::SearchBuilder::Handle::DBIHandle->{'private_profile'} = {};
  % }
  </BODY>
  </HTML>

then, to turn on profiling, (install DBIx::Profile and) put:

  PerlModule DBIx::Profile

in your Apache configuration.  If you're using Apache::DBI, you should
comment that out while using DBIx::Profile.

You'll then get a count of how many times each database query was
executed, the wallclock time etc.  This helped me immensely at figuring
out which particular things I needed to optimize rather than doing so
speculatively. 

(BTW Jesse I forget - you are using placeholders in DBIx::SearchBuilder
now?)

I have some patches to eliminate (some of) the redundant database queries
and cache ACL decisions; this speeded things up significantly in my
installation.  I'll dig them up and send them when I get a chance. 

On Fri, May 11, 2001 at 11:17:37AM +0100, Mark Vevers wrote:
> >>> On Thu, May 10, 2001 at 01:24:04PM +0200, Jonas Liljegren wrote:
> >>> 
> >>>> In 1.3.70...
> >>>> 
> >>>> The RT system is currently rather slow. Many of the pages takes 10
> >>>> seconds to build. The database has around 150 tickets.  /proc/cpuinfo
> >>>> says 76.8 bogomips.  We will move to a faster machine.  -- I just
> >>>> wanted to say that there is a reason for shortcuts...
> 
> <snip>
> 
> Jesse wrote:
> 
> > I probably wouldn't run it in production with less than a 500mhz cpu and 128
> > megs of ram in the box.  As I said though, there's ongoing performance work,
> > though it's not the highest priority thing going on.  Buying faster hardware
> > and sponsoring work on performance are both valid ways to deal with this.
> 
> I'm running RT on a dedicated dual 450MHz P3 with 512 Meg RAM, and performance
> seems to be slowing down considerably, especially when displaying long tickets.
> We only have 36 in the database with a total of 121 attachments(just starting
> to use it in our backbone team) and building some of them can take ten seconds
> before the page starts displaying. I'm sure it's not the mysql server as if
> issue the SQL commands manually it's all sub 1 second.
> 
> (And no, it's not the network either.  It's on a 100Mb full duplex feed to an
> unloaded switch on it's own vlan and FTP from here to there runs at about 97
> Mbits ..!)
> 
> Anything which updates the database takes even longer.
> 
> From the cpu usage it all seems to be disappearing into apache, so I suspect
> it is all the perl/mod-perl code.  I haven't yet looked at the source yet, but
> (I'm probably teaching you to suck eggs here)  are you using one connection 
> for all the SQL queries or opening and closing each one.   Also, are you using
> placeholders for getting the ticket contents as this means you can reuse your
> prepared SELECT statements.
> 
> I've not used Mason before so I need to get to grips with what thats up to
> before I can really go poking into the source. 
> 
> Regards
> Mark
> 
> -- 
> Mark Vevers.    mark at ifl.net / mvevers at rm.com
> Internet Backbone Engineering Team
> Internet for Learning, Research Machines Plc
> Tel: +44 1235 823380,   Fax: +44 1235 823424
> 
> 
> _______________________________________________
> Rt-devel mailing list
> Rt-devel at lists.fsck.com
> http://lists.fsck.com/mailman/listinfo/rt-devel

-- 
meow
_ivan