[Rt-devel] 3.4.0rc1 slow

David Kerry dkrt at navahonetworks.com
Fri Jan 7 13:08:07 EST 2005


Hello,

I've been spending some time with 3.4.0rc1 lately with some of
our existing data and have found some issues related to slow
or excessive database access.

Setup:

Postgres 7.4.6
RT 3.4.0rc1
SearchBuilder 1.16
Apache 2+mod_perl2 (Debian sarge)

Hardware: dual 3Ghz Xeon server

Both rt and database are on the same machine.

I have 2 issues:

1) The query builder page (when you hit the 'tickets' link) is
   exceptionally slow to initially come up.  About 10 seconds just
   to bring up the empty form.  Is this normal?

   I've looked at the postgres logs, and it seems to do many many iterations
   of this type of query:

   LOG:  duration: 1983.993 ms  statement:                                                                                         
              SELECT DISTINCT main.* FROM (Groups main LEFT JOIN Principals Principals_2 ON ( main.id = Principals_2.id)),
   ACL ACL_1 WHERE ((ACL_1.RightName = 'OwnTicket')) AND ((Principals_2.Disabled = '0')) AND ( ( ACL_1.PrincipalId = main.id AND
   ACL_1.PrincipalType = 'Group' AND ( main.Domain = 'SystemInternal' OR main.Domain = 'UserDefined' OR main.Domain =
   'ACLEquivalence')) OR ( ( (main.Domain = 'RT::Queue-Role' AND main.Instance = 102) ) AND main.Type = ACL_1.PrincipalType) ) AND
   (ACL_1.ObjectType = 'RT::System' OR (ACL_1.ObjectType = 'RT::Queue' AND ACL_1.ObjectId = 102) ) ORDER BY main.Name ASC

   At the time, there were about 50k+ users and 20k+ groups in the
   database.


2) The method used in the Postgres version of SearchBuilder/Handle/Pg.pm
   for insert() is suboptimal.  I've turned on postgres logging to dump
   any queries taking > .5 seconds and the query in this method comes up
   continually:

   ie:

   postgres[18131]: [6610-1] LOG:  duration: 881.154 ms  statement: SELECT id FROM Attachments WHERE oid = '3609306'

   From doing a bit of reading in the postgres docs, the oid should not
   be used for this type of thing - they can/will roll, which can lead
   to duplicates too.

   The same query, selecting on 'id' from the Attachments table is
   virtually instantaneous.

   I would highly recommend taking the approach used in the Oracle version
   of this class and select the next id from a sequence and insert using
   that instead of depending on the database to auto-generate an id and
   then having to figure out what id it generated.

   Alternately - use guids everywhere instead of sequences/ids - easy to
   generate, avoids duplicate key issues on imports and has many other
   benefits.

   This becomes a serious issue when you throw database replication into
   the mix too.

-- 
David Kerry



More information about the Rt-devel mailing list