Performance Design Principles - Web Layer Considerations

From Guidance Share
Jump to navigationJump to search

- J.D. Meier, Srinath Vasireddy, Ashish Babbar, Rico Mariani, and Alex Mackman


Consider state management implications.

Web layer state management involves storing state (such as client preferences) across multiple calls for the duration of a user session, or sometimes across multiple user sessions. You can evaluate your state management approach by using the following criteria: How much data and how many trips?

Consider the following options:

  • Storing data on the client. You can store data on the client and submit it with each request. If you store data on the client, you need to consider bandwidth restrictions because the additional state that needs to be persisted across calls adds to the overall page size. You should store only small amounts of data on the client so that the effect on the response time for the target bandwidth is minimal, given a representative load of concurrent users.
  • Storing data in the server process. You can store per-user data in the host process on the server. If you choose to store user data on the server, remember that the data consumes resources on the server until the session times out. If the user abandons the session without any notification to the Web application, the data continues to consume server resources unnecessarily until the session times out. Storing user data in the server process also introduces server affinity. This limits your application's scalability and generally prevents network load balancing.
  • Storing data in a remote server process. You can store per-user data in remote state store. Storing data on a remote server introduces additional performance overhead. This includes network latency and serialization time. Any data that you store must be serializable and you need to design up front to minimize the number of round trips required to fetch the data. The remote store option does enable you to scale out your solution by, for example, using multiple Web servers in a Web farm. A scalable, fault tolerant remote store such as a SQL Server database also improves application resilience.


Consider how you build output.

Web output can be HTML, XML, text, images, or some other file type. The activities required to render output include retrieving the data, formatting the data, and streaming it to the client. Any inefficiency in this process affects all users of your system.

Some key principles that help you build output efficiently include the following:

  • Avoid interspersing user interface and business logic.
  • Retain server resources such as memory, CPU, threads, and database connections for as little time as possible.
  • Minimize output concatenation and streaming overhead by recycling the buffers used for this purpose.


Implement paging.

Implement a data paging mechanism for pages that display large amounts of data such as search results screens. For more information about how to implement data paging, see "How To: Page Records in .NET Applications" at http://msdn.microsoft.com/library/en-us/dnpag/html/scalenethowto05.asp.


Minimize or avoid blocking calls.

Calls that block your Web application result in queued and possibly rejected requests and generally cause performance and scalability issues. Minimize or avoid blocking calls by using asynchronous method calls, a "fire and forget" invocation model, or message queuing.


Keep objects close together where possible.

Objects that communicate across process and machine boundaries incur significantly greater communication overhead than local objects. Choose the proper locality for your objects based on your reliability, performance, and scalability needs.