ASP.NET Best Practices

ASP.NET Best Practices

1. Caching Improves web application Performance

2. Don't give more no of request to DB .Single request to DB and get more result. Round trip time will reduced and seconds per request will improved.

3. While you can return multiple resultsets using dynamic SQL, I prefer to use stored procedures. It's arguable whether business logic should reside in a stored procedure, but I think that if logic in a stored procedure can constrain the data returned (reduce the size of the dataset, time spent on the network, and not having to filter the data in the logic tier), it's a good thing.

4. Using a SqlCommand instance and its ExecuteReader method to populate strongly typed business classes, you can move the resultset pointer forward by calling NextResult. 

5. Apply Connection Pooling in sql server to Application.

6. Dont trust CLR to for sqlconnection will automatically closed.try to closed you sql connection  when your operation was completed.

7. Use Connection Pooling (Default size:100)

8. Use Output Caching (Kernal mode Caching give more Speed).

9. Enable gzip compression in IIS will reduce the byte of response sent from server.

10. Always set debug=”false” in web.config production environment.

11. Always set trace=”false” in web.config production environment.

12. Always compile your project in Release Mode before uploading application to production environment.

13. Decrease your html kb as much as you can for that use tables less html using div’s and if possible  then do not give big name to your control it will increase your html kb as asp.net uses client Id to differentiate all the controls. If you are creating custom controls then you can overwrite your clientid and uniqueId.

14. Remove blank spaces from your html it will increase your kb. You can use regular expression t0 remove white spaces. I will post the code for removing white spaces next posts.

15. Prefer database reader over dataset unless and until you have specific reason to use database

16. Use ADO.NET asynchronous calls for ado.net methods. asp.net 2.0 or higher version is supporting your performance. If you are using same procedure or command multiple time then use ADO.NET Prepare command it will increase your performance.

17. Use  Server.Transfer instead of response.redirect.

18. Use Ajax for your application wisely. Lots of Ajax calls for a page will also decrease your performance

19. User System.Text.StringBuilder for string concatenation its 4 times more faster then the normal strings.

20. Right JavaScript in .Js files and place it as bottom of the application

21. Use Separate CSS files for styling of application

22. Call web service from java script instead of server side. Use asynchronous calls to call a web method from web service

23. Disable View State :View state is used to allow ASP.NET to keep the state of the page between postbacks performed by user. View state data is stored in HTML output inside hidden field. If your page displays many controls that contains a huge data, the view state field will be big enough to affect the response time of your page. if your page just display data without need any postback so it will be better to disable the view state of the whole page by set EnableViewState to false.

24.  Pre-Compiling ASP.NET Application:

25. When compiling an ASP.NET application project, a single assembly is created to hold all application's code but web pages(.aspx) and user controls(.ascx) not compiled and be deployed as it is. In the first request ASP.NET dynamically compiles the web pages and user control and places the compiled files in the ASP.NET temporary files folder.

To reduce the time of first request the web application can be pre-compiled, including all code, pages, and user controls, by using the ASP.NET compilation tool (Aspnet_compiler.exe). Running this tool in production servers can reduce the delay users experience on first requests.
You can pre-compile web pages in your application to reduce the working set size and boost application performance. SetAutoEventWireup attribute to false in thesection of the server's Machine.config file to improve performance further, e.g.:
   <configuration> <system.web> <pages autoEventWireup="true|false" /> </system.web>    </configuration>
You can pre-compile web pages in your application to reduce the working set size and boost application performance. SetAutoEventWireup attribute to false in thesection of the server's Machine.config file to improve performance further, e.g.:
   <configuration> <system.web> <pages autoEventWireup="true|false" /> </system.web>    </configuration>

a. Open a command prompt in your production server.

b. Navigate to the %windir%\Microsoft.Net folder

c. Navigate to either the Framework or Framework64 according to the configuration of web application's application pool.

d. Navigate to framework version's folder.

e. Enter the following command to start the compilation

Aspnet_compiler.exe  -v  /FullPathOfYourWebApplication

26. Reducing Page Load Time:

Avoid excessively large images, redundant tags, and nested tables to facilitate faster page loads. Always avoid unnecessary roundtrips to the web server. Use client side scripts to dramatically reduce server roundtrips, thereby boosting the perceived, if not the actual application performance. Take advantage of the Page.IsPostback property to avoid unnecessary server processing on a roundtrip, reducing network traffic. I suggest you leave page buffering on (it is turned on by default) for a page unless you have a specific reason to turn it off.

27. ViewState is great for storing control state but can degrade performance—especially on web sites with large page sizes. If you've ever looked at a page that contains a large DataSet, you know the amount of data stored in ViewState can be overwhelming. Every byte added to a web page by enabling its ViewState causes two bytes of network traffic, one in each direction. Evaluate whether each web page you write requires ViewState and avoid it when possible to speed up the page-load cycle in your applications. You should typically use ViewState only for controls that need to persist state. You can turn ViewState on or off at four levels: machine, application, page, and control. Limiting the size of the ViewState and eliminating its unnecessary usage would boost the application performance to a large extent due to the reduced size of the rendered pages and hence the network traffic. It should be noted that each byte of the view state causes two bytes of network traffic for each request, one from the server to the client and the other from the client to the server. For more information on ViewState and how to turn it off at control, page, application, or machine levels.

28. You can remove the runat="server" form tag completely to reduce page size by 20 bytes. If you don't remove this tag, the page itself passes on about 20 bytes of information to ViewState—even when the page's ViewState property is set to false.

29. Caching is one of the best strategies for storing relatively static application data. Caching reads data from memory to avoid repeatedly retrieving data from a database, file, or any other repository, and it can provide huge application performance gains. Use Page Output, Page Fragment or Data Caching directives depending on your requirements. Cache application-wide data that multiple users of the application need to share and access, but avoid storing user-specific data in the cache.

30. Use Session State only for storing a single user's session data. Avoid storing too many objects in the Session and turn Session State off for pages that do not need to access session data. You can turn Session State on or off at the same four levels as ViewState: machine, application, page, and control.

31. Note that there are three Session State storage modes. The right type of storage mode to choose depends on factors such as, speed, security, scalability, and reliability. Even though the InProc mode of Session State storage is the fastest, it is not at all well suited to a production environment and not scalable for large sites. The OutProc storage mode is well-suited for web sites with heavy traffic, while the SqlServer mode is great for securing session data. No matter which mode you choose though, Session State has one major disadvantage: the resource will be increasingly strained as you scale up. There are always tradeoffs. The best mode for security, scalability, and reliability is not always the best mode for performance, and vice versa.