ASP.NET MVC Performance Tips
Database access is usually the largest performance bottleneck of web applications. But once you’ve optimized and cached your database queries as much as possible here are 3 quick tips that might help you squeeze out a few more requests out of your ASP.NET MVC applications and web servers.
Depending on which features you are using they might not always apply to your application and their benefit will not be that significant (a few % points improvement at most - sorry I don't have more specific numbers as I'm writing this from memory). I can't guarantee how much improvement you will see as it depends so much on what your application does. But I hope this will provide some leads for you to investigate. Just remember to always measure for your specific scenario.
Disable unused view engines
When: Your application is using built-in display/editor templates (via the Html.EditorFor
or Html.DisplayFor
methods) and you are using only one type of view engine.
Why: ASP.NET MVC is generally very good about caching file lookup hits (views, partials, display/editor templates). However one scenario that is not cached is the use of the built-in (default) display/editor templates (where all file lookups are misses).
Any time you use the Html.EditorFor
or Html.DisplayFor
methods and you do not have a matching template file MVC will generate the appropriate markup for you based on the model’s metadata. However, before that happens it checks all the view engines to find a template file. The more view engines you have registered the longer this will take and since the miss is not cached the process will have to be repeated the next time a page is requested. If you are using only one view engine in your project you should remove the other ones in Global.asax. The easies way to do that is with the following code:
ViewEngines.Engines.Clear();
ViewEngines.Engines.Add(new RazorViewEngine());
Avoid passing null models to views
When: You pass in a null model to a view that uses strongly-typed html helpers (such as Html.TextBoxFor
). This frequently happens in Insert scenarios.
Why: Strongly-typed html helpers such as Html.TextBoxFor(m => m.Name)
will try to emit the value of the model using the provided expression. However when something along the expression chain is null a NullReferenceException will be thrown when the expression gets evaluated. MVC’s expression evaluator catches the exception but on a page with multiple such html helpers the cost of the exception adds up. You can avoid that cost by always passing an instance of the model to the view:
public ActionResult Insert() {
// return View(); // here the model instance defaults to null
return View(new Product());
}
Uninstall URL Rewrite if you don’t use it
When: Your IIS server has the URL Rewrite module installed but none of the applications on the server are using it and you are running ASP.NET MVC 3.
Why: When performing URL generation (for example via a method like Html.ActionLink
) in some cases MVC checks to see if the currently requested URL has been rewritten by the URL Rewrite module. If that is the case the result is processed so that it correctly matches the URL requested by the client.
The act of checking if a URL has been rewritten has a non-trivial cost (because it involves checking server variables). ASP.NET MVC 3 checks to see if URL Rewrite is turned off and can cache that fact thus avoiding the need to inspect server variables for each request. If URL Rewrite is turned on MVC will have to check server variables even if no rewriting happened for a particular request so if you are not using URL Rewrite you should turn it off (Note that MVC 2 always performs this check so turning URL Rewrite off will not make a difference).
Comments
Anonymous
February 07, 2011
Thanks for the tips. ArunAnonymous
February 07, 2011
good for dearAnonymous
February 07, 2011
thanksAnonymous
February 07, 2011
Great tips, thanks!Anonymous
February 08, 2011
Good tips. Thanks.Anonymous
February 08, 2011
I have a website on my server that uses the URL Rewrite. Would it be worth the performance gain to rewrite it using MVC? Marcin's Response: Hard to say, though it's probably not worth it. The savings wouldn't be that great if at all (you would be moving the rewriting work elsewhere) and the server variables collection might be retrieved by something else in your application so you wouldn't be saving anything. This suggestion is meant as a last resort when you can't gain any more performance using more mainstream approaches such as database query optimization or output caching.Anonymous
February 09, 2011
Nice commentsAnonymous
May 15, 2011
Nice article asp-net-csharp-vb.blogspot.comAnonymous
May 15, 2011
Nice article asp-net-csharp-vb.blogspot.com