[rt-users] performance question

Filip Rembialkowski filip.rembialkowski at eo.pl
Thu Nov 30 05:13:51 EST 2006


On Wed, November 29, 2006 17:17, Jesse Vincent wrote:
>
> On Nov 29, 2006, at 6:34 AM, Filip Rembialkowski wrote:
>
>> hi all RT users,
>>
>> at my work we have such setup:
>>
>> 135 queues
>> 49000 tickets
>>
>> RT 3.4.1 running on
>> Apache/1.3.33 (Debian GNU/Linux) mod_perl/1.29, Perl 5.8.4
>>
>> I was running a test for following scenario:
>> . Connect to web interface
>> . Login as root
>> . Display one random queue
>> . Search for one random ticket using the top search box
>> . Logout
>>
>> After enabling query logging, I have observed that running above
>> scenario
>> _once_ resulted in almost 1500 queries to my postgresql backend. so
>> this
>> is 1500 queries for the scenario, which essentially consists of
>> displaying
>> 3 pages:
>>
>> 1) home page with standard settings (queues visible on the right side,
>>  top10 and unowned in the middle)
>> 2) the page with one particular queue
>> 3) the page with one particular ticket
>>
>> i have also enabled detailed query logging, and observed that about
>> 60% of
>> database time is spent on queries which are used for ACL checking.
>>
>> so... my question is: is this normal?
>
> That sounds surprisingly high. But you're also testing with
> an...older RT. And I know we've made some big performance
> improvements since then. I can't guarantee that we've fixed whatever
> you're running into, but coming up to 3.4.6 or 3.6 is strongly
> recommended.
>
>
actually i discovered this while evaluating RT 3.6.1 :)
I was talking about 3.4.1, because the results are very similar.

to be precise, I made this test again, just for a single home page view,
and have posted SQL log for single home page view here:
http://depesz.com/various/rt-3.6.1-homepage-view-sql-log.html
if you look at this, you will know what I mean

so the question is still valid.
is it needed to ask all these queries?
can we optimize it somehow?

greets,
Filip





More information about the rt-users mailing list