On Thu, Mar 29, 2012 at 1:52 PM, Daniel Drake <[email protected]> wrote: > 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).
Sad, track is coded by SQL-defficient programmers. <rant> All webbased CMSs go through this hell, and a bugtracker is a form of CMS. "Oh, I don't know SQL, but, here, I added a permissions system". People paper over the horrid scalability with clumsy caching schemes and usually everyone suffers forevermore. We had the great Moodle debacle of v1.7 to 1.8, that got fixed when I rewrote the whole thing to execute in a _constant number of queries_, regardless of nr of users, usergroups/roles, nested "contexts", "capabilities" used, overrides applied, etc. It was a gigantic pain, but hey, you can't tell universities to limit their enrolmentsbecause your system can't cope :-) While I was working on this, a colleague told me he had been through the *same* hell with Ars Digita's original CMS, back in the dawn of the Interwebs, and that even today that CMS (or its Java reincarnation) is pottering about with harebrained caching schemes. Bound number of SQL queries is the fix. But damn it is hard, and the pretty OOB DB APIs make this harder to fix. </rant> > http://trac.edgewall.org/ticket/4245 they've known about this for _years_. What a $#$@#$@. m -- [email protected] [email protected] -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
