Tags


Performance Improvement Points for ASP.Net Website

Design

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

Page

  • 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.

 

Caching

  • 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.

 

GC

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

 

 

 

DataBase

Schema

  • 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.

 

Queries

  • 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.

 

Indexes

  • 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

clauses.

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

 

Transaction

  • 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.

 

Exception

  • 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.

 

ADO.Net

  • 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

 

Connection

  • 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.

 

Command

  • 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

 

Params

  • 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.

 

DataReader

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

 

DataSet

  • 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.

 

Caching

  • 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.

DataAccess

  • 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.

Enjoy!

Advertisements