Performance Improvement Points for ASP.Net Website


  • Partition your application logically.
  • Reduce round trips.
  • Avoid blocking on long-running tasks.
  • Use caching.
  • Avoid unnecessary exceptions.


  • Trim your page size.
  • Enable buffering.
  • Use Page.IsPostBack to minimize redundant processing.
  • Partition page content to improve caching efficiency and reduce rendering.
  • Ensure pages are batch compiled.
  • Ensure debug is set to false.
  • Optimize expensive loops.
  • Consider using Server.Transfer instead of Response.Redirect.
  • Use client-side validation.

Server Control

  • Identify the use of view state in your server controls.
  • Use server controls where appropriate.
  • Avoid creating deep hierarchies of controls.


Data Binding

  • Avoid using Page.DataBind.
  • Minimize calls to DataBinder.Eval.



  • Separate dynamic data from static data in your pages.
  • Configure the memory limit.
  • Cache the right data.
  • Refresh your cache appropriately.
  • Cache the appropriate form of data.
  • Use output caching to cache relatively static pages.
  • Choose the right cache location.
  • Use VaryBy attributes for selective caching.


State Management

  • Store simple state on the client where possible.
  • Consider serialization costs.



Application State

  • Use static properties instead of the Application object to store application state.
  • Use application state to share static, read-only data.


Session State

  • Prefer basic types to reduce serialization costs.
  • Disable session state if you do not use it.
  • Avoid storing COM objects in session state.
  • Use the ReadOnly attribute when you can.


View State

  • Disable view state if you do not need it.
  • Minimize the number of objects you store in view state.
  • Determine the size of your view state.


Http Module

  • Avoid long-running and blocking calls in pipeline code.
  • Consider asynchronous events.


String Management

  • Use Response.Write for formatting output.
  • Use StringBuilder for temporary buffers.
  • Use HttpTextWriter when building custom controls.


Exception Management

  • Implement a Global.asax error handler.
  • Monitor application exceptions.
  • Use try/finally on disposable resources.
  • Write code that avoids exceptions.
  • Set timeouts aggressively.


Data Access

  • Use paging for large result sets.
  • Use a DataReader for fast and efficient data binding.
  • Prevent users from requesting too much data.
  • Consider caching data.


Deployment Consideration

  •  Avoid unnecessary process hops.
  • Configure the memory limit.
  • Disable tracing and debugging.
  • Avoid XCOPY under heavy load.
  • Consider precompiling pages.
  • Consider using HTTP compression.
  • Consider using perimeter caching.



Class Design

  • Do not make classes thread safe by default.
  • Consider using the sealed keyword.
  • Consider using overloaded methods.
  • Consider overriding the Equals method for value types.
  • Know the cost of accessing a property.
  • Consider private versus public member variables.
  • Limit the use of volatile fields.



  • Avoid calling GC.Collect.
  • Set unneeded member variables to Null bef






  • Devote the appropriate resources to schema design.
  • Normalize first, denormalize later for performance.
  • Define all primary keys and foreign key relationships.
  • Define all unique constraints and check constraints.
  • Choose the most appropriate data type.
  • Use indexed views for denormalization.
  • Partition tables vertically and horizontally.



  • Know the performance and scalability characteristics of queries.
  • Write correctly formed queries.
  • Return only the rows and columns needed.
  • Avoid expensive operators such as NOT LIKE.
  • Avoid explicit or implicit functions in WHERE clauses.
  • Use locking and isolation level hints to minimize locking.
  • Use stored procedures or parameterized queries.
  • Minimize cursor use.
  • Avoid long actions in triggers.
  • Use temporary tables and table variables appropriately.
  • Limit query and index hint use.
  • Fully qualify database objects.



  • Create indexes based on use.
  • Keep clustered index keys as small as possible.
  • Consider range data for clustered indexes.
  • Create an index on all foreign keys.
  • Create highly selective indexes.
  • Create a covering index for often-used, high-impact queries.
  • Use multiple narrow indexes rather than a few wide indexes.
  • Create composite indexes with the most restrictive column first.
  • Consider indexes on columns used in WHERE, ORDER BY, GROUP BY, and DISTINCT


  • Remove unused indexes.
  • Use the Index Tuning Wizard.



  • Avoid long-running transactions.
  • Avoid transactions that require user input to commit.
  • Access heavily used data at the end of the transaction.
  • Use isolation level hints to minimize locking.
  • Ensure that explicit transactions commit or roll back


Stored Procedure

  • Use Set NOCOUNT ON in stored procedures.
  • Do not use the sp_prefix for custom stored procedures.



  • Evaluate the query execution plan.
  • Avoid table and index scans.


Execution Plan

  • Use stored procedures or parameterized queries.
  • Use sp_executesql for dynamic code.
  • Avoid interleaving data definition language (DDL) and data manipulation language (DML) in

stored procedures, including the tempdb database DDL.

  • Avoid cursors over temporary tables.



  • Design your data access layer based on how the data is used.
  • Cache data to avoid unnecessary work.
  • Connect by using service accounts.
  • Acquire late, release early.
  • Close disposable resources.
  • Reduce round trips.
  • Return only the data you need.
  • Choose the appropriate transaction type.
  • Use stored procedures.
  • Consider how to handle exceptions.
  • Use appropriate normalization



  • Open and close the connection in the method.
  • Explicitly close connections.
  • When using DataReaders, specify CommandBehavior.CloseConnection.
  • Do not explicitly open a connection if you use Fill or Update for a single operation.
  • Pool connections.



  • Validate SQL input and use Parameter objects.
  • Retrieve only the columns and rows you need.
  • Support paging over large result sets.
  • Batch SQL statements to reduce round trips.
  • Use ExecuteNonQuery for commands that do not return data.
  • Use ExecuteScalar to return single values.
  • Use CommandBehavior.SequentialAccess for very wide rows or for rows with binary large
  • objects (BLOBs).
  • Do not use CommandBuilder at run time.


Stored Procedure

  • Use stored procedures.
  • Use CommandType.StoredProcedure with SqlCommand.
  • Consider using Command.Prepare.
  • Use output parameters where possible.
  • Consider SET NOCOUNT ON for SQL Server



  • Use the Parameters collection when you call a stored procedure.
  • Use the Parameters collection when you build SQL statements.
  • Explicitly create stored procedure parameters.
  • Specify parameter types.
  • Cache stored procedure SqlParameter objects.



  • Close DataReader objects.
  • Consider using CommandBehavior.CloseConnection to close connections.
  • Cancel pending data.
  • Consider using CommandBehavior.SequentialAccess with ExecuteReader.



  • Reduce serialization.
  • Use primary keys and Rows.Find for indexed searching.
  • Use a DataView for repetitive non-primary key searches.
  • Use the optimistic concurrency model for datasets.



  • Use caching for data that is expensive to retrieve, compute, and render.
  • Cache appropriate data such as relatively static Web pages, specific items of output data, stored procedure parameters, and query results.
  • Do not use caching for data that is too volatile.
  • Select an appropriate cache location.
  • Select an appropriate cache expiration policy.


State Management

  • Your design favors stateless components. Or, you considered the negative impact on scalability if you decided to use stateful components.
  • Consider the performance impact of view state.
  • Use statistics relating to the number of concurrent sessions and average session dataper user to help choose an appropriate session state store.


  • Pass data across the layers by using the most appropriate data format. Carefully consider the performance implications.
  • Use stored procedures with the Parameters collection for data access.
  • Only process the data that is required.
  • Where appropriate, provide data paging solutions for large result sets.
  • Use Enterprise Services declarative transactions for transactions that span multiple resource managers or where you need to flow transaction context across components.


Exception Handling

  • Do not use exceptions to control regular application flow.
  • Use well-defined exception handling boundaries.
  • Structured exception handling is the preferred error handling mechanism. Do not rely on error codes.
  • Only catch exceptions for a specific reason and when it is required.