Trac slowness diagnosis

[Daniel Drake]

Hi,

Yesterday, I imported our trac database into trac 0.12.3 on a separate
machine and found that even on such a setup, each ticket page was
taking 19 seconds to load (same as the production server at
dev.laptop.org).

Through some profiling I found that an inefficient trac design causes
about 17,000 identical SQL queries to be executed during each page
load, related to the number of users in the system (we have about
5.5k).

Running the same test today seems faster on both systems. Not sure why
- James did clean up some user accounts on the production system, but
my test instance still has the same database. So I'm going to leave
this for now as speeds are acceptable. Loading a ticket page in
production takes 2.5 seconds, and in my test environment 4.3 seconds.

The main cause of this slowness is that we choose to display potential
ticket owners as a drop-down list (rather than a text entry field, the
trac default). The performance issues are well known:
http://trac.edgewall.org/ticket/4245

Martin points out the disadvantage of the text entry field: it lets
you assign a ticket to a user account that doesn't exist.

Nevertheless, if things become very slow again, I think we should
switch to the text field and benefit from a huge speedup. Will keep an
eye on it.

Daniel