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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel