Alec Thomas wrote:
> On 11/28/07, Jonas Borgström <[EMAIL PROTECTED]> wrote:
>
>> While porting the t.e.o theme to Trac trunk I noticed that the /roadmap
>> is very slow, and it takes at least 1.5-2 seconds to render that page.
>>
>
> I was wondering if the permission system would have an impact, given how
> much work it has to do.
>
>
Ouch, is that compared to the +/- 250ms it currently takes for the
/roadmap content alone (not considering the secondary requests).
Otherwise, rendering the full page already takes about that time.
>> Almost all of that time is apparently spent by the permission system
>> making sure the user isn't shown any ticket he/she isn't supposed to
>> see:
>>
>> (roadmap.py:267)
>> def apply_ticket_permissions(env, req, tickets):
>> """Apply permissions to a set of milestone tickets as returned by
>> get_tickets_for_milestone()."""
>> return [t for t in tickets
>> if 'TICKET_VIEW' in req.perm('ticket', t['id'])]
>>
>> If I'm reading perm.py correctly PermissionCache only caches repeated
>> permission checks on a specific resource and action and not repeated
>> checks on different resources in the same realm. This means that the
>> apply_ticket_permission function will generate hundreds if not thousands
>> of cache misses for larger Trac installations.
>>
> Correct. All permission checks are handed off to IPermissionPolicy
> implementations, so it's impossible (currently) for the permission
> system to know whether more aggressive caching is acceptable.
>
Alec, I think either you misinterpreted his question, or I'm
misinterpreting it.
In the scope a given request, there will be only one cache miss for a
given resource/action. That's because the actual _cache of permissions
is shared from one PermissionCache instance to another. So "repeated
checks on different resources in the same realm" (or not in the same
realm for that matter) are indeed cached.
A different approach would be to move that _cache at the level of the
PermissionSystem component, in order to share it across requests, with
the user as a toplevel key and some mechanism to prune that cache. The
trade-offs there would be on the down side some degree of locking
contention on that cache, on the up side, the decisions for /all/
permission policies would be cached and the checks won't have to be
repeated for every request.
-- Christian
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
