Security Trimming Overhead?

Nov 3, 2010 at 11:25 AM
Edited Nov 3, 2010 at 11:26 AM

Hi There

Had a number of looks at MVC SiteMap over the past year & finally downloaded & had a play today. What I noticed pretty quickly is how much overhead there seems to be with security trimming enabled?

E.g. In Branch 2.2.1, navigating between browse categories takes (for my environment) approx 50ms, but with security trimming enabled it takes approx 600ms. Rendering the site map takes 6 seconds with security trimming enabled. This is with debugging disabled, in VS2010, or deployed on IIS - no changes to the sample app, other than changing the security trimming setting.

Is this about right, or is something awry at my end?


FYI - dev environment is I7 Quad, SSD, 8Gb - things just seem snail pace compared to any other MVC apps I've developed/deployed...

Would love to use in a fairly large project that I'm in the middle of & need a cleaner sitemap solution for, so hoping that I'm just missing something!





Nov 4, 2010 at 8:17 PM

It's unfortunate but currently the only way to go... By defaukt, every controller/action is checked for permissions, and for every controller/action a new controller instance is being resolved.

I am planning some caching on this, but for now it's the only way to go... A work item is in place for these performance issues:

Nov 4, 2010 at 11:38 PM

Thanks for that. What I ended up doing was moving this process to the actual sitemap build. I.e. adding the Action/Controller authorise logic to the node roles. This way it's all stored in the cached sitemap. Works for me anyway, I can now leave all the authorisation logic to the controller/Action Authorise Attributes.... Great work by the way, Joe