Trac slowness diagnosis

[Martin Langhoff]

On Thu, Mar 29, 2012 at 1:52 PM, Daniel Drake <dsd at laptop.org> 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
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff