Forum OpenACS Q&A: Re: Incredible Performance Decrease - Please help!!!

Collapse
Posted by Don Baccus on
Also ... looking forward to the future, one thing we've discussed is to reduce the number of privileges defined in the system (all those 'forum_read' or "portal_read" type privileges that are children of 'read' and which could just be 'read').  The permission queries look to be O(n) in the number of distinct privileges defined in the system, so if we shrink the number from the thirty or forty or fifty or whatever we see in a .LRN installation to ten or so we'll see a nice speed-up.

And the portal system rewrite creates many fewer objects, which should help a bit.

Collapse
Posted by Lars Pind on
Branimir told me about a change they'd made, which is to have each privilege show up as columns in one wide table, so there's at most one row per (party x object). The table has a fixed number of columns (say a few hundred, to be on the safe side) with generic names (p1, p2, p3, ...), and this is automatically handled by the Tcl layer.

This is in addition to the normal table, but it also flattens the privilege hierarchy, so if read is a child of admin, then the uber-row would have a check mark in both the "read" and "admin" columns.

According to Branimir, it made permissions checks much faster. Not sure about the details why and how, but I'd guess that smaller indices due to fewer rows would make it faster, as well as the flattening of the privilege hierarchy, and you might avoid some 'select distinct' and other expensive operations, because there's only one row per party/object.

Aram is the chief architect behind this, so is the person to ask for details.

/Lars