Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#3962 closed task (fixed)

trac is slow: migrate to pgsql from sqlite

Reported by: tomek Owned by:
Priority: very high Milestone: Kea1.0-beta
Component: trac Version: git
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: Core Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no


As discussed with our OPS, they strongly recommend to migrate from sqlite to postgres as trac database.


Change History (5)

comment:1 Changed 4 years ago by hschempf

  • Milestone changed from Kea-proposed to Kea1.0
  • Priority changed from medium to high

Per 8/12 team meeting, move to 1.0 High

comment:2 Changed 4 years ago by fdupont

  • Priority changed from high to very high

comment:3 Changed 4 years ago by fdupont

According to #4084 the source of trac slowness is more in the HTML generation...

comment:4 Changed 4 years ago by stephen

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

In fact, the problem was due to a configuration option:

Some of the Kea community may have noticed that the Trac site was 
getting slower and slower. For the Trac team it was becoming unbearable, 
especially when tasks like updating tickets or generating reports were 
taking over thirty seconds when should be instant.

In the trac.ini [ticket] section, I changed restrict_owner from true to 
false. Great speed up. It is a known Trac issue with multiple Trac 
tickets, including The problem is 
related to have too many user accounts and its inefficiency with 
checking privileges for each. (I have no idea why it checks these 
privileges for the slow HTML reports but not for the fast RSS reports.)

(Sorry I overlooked this before, as it was briefly noted also in and

This means that "review to" and "reassign to" ticket actions now are 
text field entry boxes and no longer a drop-down menu of username 
choices. I think we can live with this until we prune out all the many 
user accounts from the Kea Trac site. (Most are spammers.)

My plan is to somehow see if the Trac users have legitimate Kea wiki or 
Kea ticket contributions. If not, remove the bogus user account. Once we 
get the list of users down to some small amount (I guess less than 30 
legitimate), we can try to renable the restrict_owner=true.

If you notice any other issues related to the "restrict_owner=false" 
change, please let me know.

We have several other Trac changes to consider (like new plugins), but 
we were waiting for the Trac performance to be solved first. Maybe in 
two weeks we can verify this change is okay and then start with those 
tasks then.

-- Jeremy Reed

comment:5 Changed 4 years ago by tomek

  • Milestone changed from Kea1.0 to Kea1.0-beta

Milestone renamed

Note: See TracTickets for help on using tickets.