Edgewall Software
Modify

Ticket #7678 (closed defect: duplicate)

Opened 4 years ago

Last modified 4 years ago

Repeated query inefficiencies

Reported by: pickscrape@… Owned by:
Priority: normal Milestone:
Component: general Version: 0.11
Severity: normal Keywords:
Cc:
Release Notes:
API Changes:

Description

I just discovered that trac issues the following query:

SELECT username,action FROM permission;

At least 74 times per page on my trac install.

Looking at my query logs, 74 just happens to be the number of rows returned by this query:

   SELECT DISTINCT s.sid, n.value, e.value
     FROM session AS s
LEFT JOIN session_attribute AS n
       ON (n.sid=s.sid   and n.authenticated=1
      AND  n.name = 'name')
LEFT JOIN session_attribute AS e
       ON (e.sid=s.sid
      AND  e.authenticated=1
      AND  e.name = 'email')
    WHERE s.authenticated=1
 ORDER BY s.sid;

Which gets run before the repeated query.

On the roadmap page the query is run 1333 times, which just happens to be the number of milestones we have (18) times 74 + 1 (in this case that adds up to something like 200ms of additional page runtime). On that page the query to get the list of users is also run once per milestone. Other queries are also run multiple times (e.g. SELECT name,value FROM enum WHERE type='severity' ORDER BY CAST(value AS int)).

Furthermore, we don't actually have 74 active users: that number is more like 23, The 74 includes all users that we have ever had, most of which have been removed from within the Admin UI.

Obviously, this doesn't look right. I have had a look at the code, and there appears to be a number of functions in trac/perm.py that run these queries with no caching, so every time they are called the queries are run again with the same results.

There may be some factor here that I'm not aware of, but adding caching to some of these functions seems like quite an easy way to make trac a lot more efficient.

Attachments

Change History

comment:1 follow-up: Changed 4 years ago by rblank

This might be related to #6436.

comment:2 Changed 4 years ago by anonymous

  • Version set to 0.11

Forgot to specify the version.

comment:3 in reply to: ↑ 1 Changed 4 years ago by cboos

Replying to rblank:

This might be related to #6436.

Could be, yes.

@pickscrape, do you have the following setting in your trac.ini file?

[ticket]
restrict_owner = true

Does turning it off make a difference for your measuring?

comment:4 follow-up: Changed 4 years ago by pickscrape

We do have that turned on yes. I'll try the experiment you suggest later on today once all other users have gone home.

comment:5 in reply to: ↑ 4 Changed 4 years ago by cboos

  • Resolution set to duplicate
  • Status changed from new to closed

Replying to pickscrape:

We do have that turned on yes.

See #6436.

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
to The owner will be changed from (none). Next status will be 'closed'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.