A compiled list of possible sources of improvement are below:
General
- Make use of a profiler to discover memory leaks and performance problems in your application. personally I suggest dotTrace
- Run your site in Release mode, not Debug mode, when in production, and also during performance profiling. Release mode is much faster. Debug mode can hide performance problems in your own code.
Caching
- Use
CompiledQuery.Compile()
recursively avoiding recompilation of your query expressions - Cache not-prone-to-change content using
OutputCacheAttribute
to save unnecessary and action executions - Use cookies for frequently accessed non sensitive information
- Utilize ETags and expiration - Write your custom
ActionResult
methods if necessary - Consider using the
RouteName
to organize your routes and then use it to generate your links, and try not to use the expression tree based ActionLink method. - Consider implementing a route resolution caching strategy
- Put repetitive code inside your
PartialViews
, avoid render it xxxx times: if you end up calling the same partial 300 times in the same view, probably there is something wrong with that. Explanation And Benchmarks
Routing
- Use
Url.RouteUrl("User", new { username = "joeuser" })
to specify routes. ASP.NET MVC Perfomance by Rudi Benkovic - Cache route resolving using this helper
UrlHelperCached
ASP.NET MVC Perfomance by Rudi Benkovic
Security
- Use Forms Authentication, Keep your frequently accessed sensitive data in the authentication ticket
DAL
- When accessing data via LINQ rely on IQueryable
- Leverage the Repository pattern
- Profile your queries i.e. Uber Profiler
- Consider second level cache for your queries and add them an scope and a timeout i.e. NHibernate Second Cache
Load balancing
- Use Asynchronous Controllers to implement actions that depend on external resources processing.
Client side
- Optimize your client side, use a tool like YSlow for suggestions to improve performance
- Use AJAX to update components of your UI, avoid a whole page update when possible.
- Consider implement a pub-sub architecture -i.e. Comet- for content delivery against reload based in timeouts.
- Move charting and graph generation logic to the client side if possible. Graph generation is a expensive activity. Deferring to the client side your server from an unnecessary burden, and allows you to work with graphs locally without make a new request (i.e. Flex charting, jqbargraph, MoreJqueryCharts).
- Use CDN's for scripts and media content to improve loading on the client side (i.e. Google CDN)
- Minify -Compile- your JavaScript in order to improve your script size
- Keep cookie size small, since cookies are sent to the server on every request.
- Consider using DNS and Link Prefetching when possible.
Global configuration
- If you use Razor, add the following code in your global.asax.cs, by default, Asp.Net MVC renders with an aspx engine and a razor engine. This only uses the RazorViewEngine.
ViewEngines.Engines.Clear(); ViewEngines.Engines.Add(new RazorViewEngine());
- Add gzip (HTTP compression) and static cache (images, css, ...) in your web.config
<system.webServer> <urlCompression doDynamicCompression="true" doStaticCompression="true" dynamicCompressionBeforeCache="true"/> </system.webServer>
- Remove unused HTTP Modules
- Flush your HTML as soon as it is generated (in your web.config) and disable viewstate if you are not using it
<pages buffer="true" enableViewState="false"
The basic suggestion is to follow REST principles and the following points ties some of these principals to the ASP.NET MVC framework:
- Make your controllers stateless - this is more of a 'Web performance / scalability' suggestion (as opposed to micro/machine level performance) and a major design decision that would affect your applications future - especially in case it becomes popular or if you need some fault tolerance for example.
- Do not use Sessions
- Do not use tempdata - which uses sessions
- Do not try to 'cache' everything 'prematurely'.
- Use Forms Authentication
- Keep your frequently accessed sensitive data in the authentication ticket
- Use cookies for frequently accessed non sensitive information
- Make your resources cachable on the web
- Utilize ETags
- Use expiration
- Write your custom ActionResult classes if necessary
- Utilize reverse proxies
- Compile your JavaScript. There is Closure compiler library to do it as well (sure there are others, just search for 'JavaScript compiler' too)
- Use CDNs (Content Delivery Network) - especially for your large media files and so on.
- Consider different types of storage for your data, for example, files, key/value stores, etc. - not only SQL Server
- Last but not least, test your web site for performance
No comments:
Post a Comment