I've installed MVC Site Map Provider for MVC5 and just used everything out of the the box. It works fine. Now I want to implement roles based menu trimming so assuming my controller:
public class Home: Controller
{
[Authorize(Roles="Admin")]
public ActionResult Index()
{
return View();
}
}
Now basically only Admin role users can see the menu. Perfect works fine.
Also to implement this I added to my web.config this line:
<add key="MvcSiteMapProvider_SecurityTrimmingEnabled" value="true" />
The problem is that it works but it's slow. It takes about 7 seconds for the page to load. If I remove the web.config line, basically removing menu trimming based on roles it takes ~300ms for the page to load. Something is wrong in here.
Any ideas why my menu trimming based on roles is slow? I haven't done any customizations.
The security trimming feature relies on creating a controller instance for every node in order to determine if the current user context has access.
The most likely cause of this slowness is that your controllers (or their base class) have too much heavy processing happening in the constructor.
The above example will add 300 ms to the page load time for every node that represents an action method in the
HomeController
. If your other controllers also have heavy processing during instantiation, they will also add additional time to each page load.When following DI best practices, this is not an issue because heavy processing takes place in external services after the controller instance is created.
Notice in the above example that no heavy processing happens in the constructor? This means that creating an instance of
HomeController
is very cheap. It also means that action methods that don't require the heavy processing to happen (as inAbout()
andContact()
in the example) won't take the hit of heavy processing required byIndex()
.If not using DI, MVC still requires that a new controller instance be created for each request (controller instances are never shared between users or action methods). Although, in that case it is not as noticeable on a per user basis because only 1 instance is created per user. Basically,
MvcSiteMapProvider
is slowing down because of a pre-existing issue with your application (which you can now fix).Even if you are not using DI, it is still a best practice to defer heavy processing until after the controller instance is created.
But if moving heavy processing into external services in your application is not an option, you can still defer processing until its needed by moving the processing into another method so it is not too expensive to create controller instances.
Although there is a bug posted for Route values not preserved correctly in v4?
But looks like it was fixed in version 4 next release.
Another Workaround to fix this problem is cache here is a related article.
MVC siteMap provider cache