A Tech Log

December 1, 2008

ASP.NET Performance Checklist

Filed under: Development — adallow @ 11:31 pm
Tags: ,

Design Considerations

ms998596.checkbox(en-us,MSDN.10).gif Consider security and performance.
ms998596.checkbox(en-us,MSDN.10).gif Partition your application logically.
ms998596.checkbox(en-us,MSDN.10).gif Evaluate affinity.
ms998596.checkbox(en-us,MSDN.10).gif Reduce round trips.
ms998596.checkbox(en-us,MSDN.10).gif Avoid blocking on long-running tasks.
ms998596.checkbox(en-us,MSDN.10).gif Use caching.
ms998596.checkbox(en-us,MSDN.10).gif Avoid unnecessary exceptions.

Threading

ms998596.checkbox(en-us,MSDN.10).gif Tune the thread pool by using the formula to reduce contention.
ms998596.checkbox(en-us,MSDN.10).gif Consider minIoThreads and minWorkerThreads for burst load.
ms998596.checkbox(en-us,MSDN.10).gif Do not create threads on a per-request basis.
ms998596.checkbox(en-us,MSDN.10).gif Avoid blocking threads.
ms998596.checkbox(en-us,MSDN.10).gif Avoid asynchronous calls unless you have additional parallel work.

Resource Management

ms998596.checkbox(en-us,MSDN.10).gif Pool resources.
ms998596.checkbox(en-us,MSDN.10).gif Explicitly call Close or Dispose on resources you open.
ms998596.checkbox(en-us,MSDN.10).gif Do not cache or block on pooled resources.
ms998596.checkbox(en-us,MSDN.10).gif Know your application allocation pattern.
ms998596.checkbox(en-us,MSDN.10).gif Obtain resources late and release them early.
ms998596.checkbox(en-us,MSDN.10).gif Avoid per-request impersonation.

Pages

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

Server Controls

ms998596.checkbox(en-us,MSDN.10).gif Identify the use of view state in your server controls.
ms998596.checkbox(en-us,MSDN.10).gif Use server controls where appropriate.
ms998596.checkbox(en-us,MSDN.10).gif Avoid creating deep hierarchies of controls.

Data Binding

ms998596.checkbox(en-us,MSDN.10).gif Avoid using Page.DataBind.
ms998596.checkbox(en-us,MSDN.10).gif Minimize calls to DataBinder.Eval.

Caching

ms998596.checkbox(en-us,MSDN.10).gif Separate dynamic data from static data in your pages.
ms998596.checkbox(en-us,MSDN.10).gif Configure the memory limit.
ms998596.checkbox(en-us,MSDN.10).gif Cache the right data.
ms998596.checkbox(en-us,MSDN.10).gif Refresh your cache appropriately.
ms998596.checkbox(en-us,MSDN.10).gif Cache the appropriate form of data.
ms998596.checkbox(en-us,MSDN.10).gif Use output caching to cache relatively static pages.
ms998596.checkbox(en-us,MSDN.10).gif Choose the right cache location.
ms998596.checkbox(en-us,MSDN.10).gif Use VaryBy attributes for selective caching.
ms998596.checkbox(en-us,MSDN.10).gif Use kernel caching on Microsoft® Windows Server™ 2003.

State Management

ms998596.checkbox(en-us,MSDN.10).gif Store simple state on the client where possible.
ms998596.checkbox(en-us,MSDN.10).gif Consider serialization costs.

Application State

ms998596.checkbox(en-us,MSDN.10).gif Use static properties instead of the Application object to store application state.
ms998596.checkbox(en-us,MSDN.10).gif Use application state to share static, read-only data.
ms998596.checkbox(en-us,MSDN.10).gif Do not store single-threaded apartment (STA) COM objects in application state.

Session State

ms998596.checkbox(en-us,MSDN.10).gif Prefer basic types to reduce serialization costs.
ms998596.checkbox(en-us,MSDN.10).gif Disable session state if you do not use it.
ms998596.checkbox(en-us,MSDN.10).gif Avoid storing STA COM objects in session state.
ms998596.checkbox(en-us,MSDN.10).gif Use the ReadOnly attribute when you can.

View State

ms998596.checkbox(en-us,MSDN.10).gif Disable view state if you do not need it.
ms998596.checkbox(en-us,MSDN.10).gif Minimize the number of objects you store in view state.
ms998596.checkbox(en-us,MSDN.10).gif Determine the size of your view state.

HTTP Modules

ms998596.checkbox(en-us,MSDN.10).gif Avoid long-running and blocking calls in pipeline code.
ms998596.checkbox(en-us,MSDN.10).gif Consider asynchronous events.

String Management

ms998596.checkbox(en-us,MSDN.10).gif Use Response.Write for formatting output.
ms998596.checkbox(en-us,MSDN.10).gif Use StringBuilder for temporary buffers.
ms998596.checkbox(en-us,MSDN.10).gif Use HtmlTextWriter when building custom controls.

Exception Management

ms998596.checkbox(en-us,MSDN.10).gif Implement a Global.asax error handler.
ms998596.checkbox(en-us,MSDN.10).gif Monitor application exceptions.
ms998596.checkbox(en-us,MSDN.10).gif Use try/finally on disposable resources.
ms998596.checkbox(en-us,MSDN.10).gif Write code that avoids exceptions.
ms998596.checkbox(en-us,MSDN.10).gif Set timeouts aggressively.

COM Interop

ms998596.checkbox(en-us,MSDN.10).gif Use ASPCOMPAT to call STA COM objects.
ms998596.checkbox(en-us,MSDN.10).gif Avoid storing COM objects in session state or application state.
ms998596.checkbox(en-us,MSDN.10).gif Avoid storing STA components in session state.
ms998596.checkbox(en-us,MSDN.10).gif Do not create STA components in a page constructor.
ms998596.checkbox(en-us,MSDN.10).gif Supplement classic ASP Server.CreateObject with early binding.

Data Access

ms998596.checkbox(en-us,MSDN.10).gif Use paging for large result sets.
ms998596.checkbox(en-us,MSDN.10).gif Use a DataReader for fast and efficient data binding.
ms998596.checkbox(en-us,MSDN.10).gif Prevent users from requesting too much data.
ms998596.checkbox(en-us,MSDN.10).gif Consider caching data.

Security Considerations

ms998596.checkbox(en-us,MSDN.10).gif Constrain unwanted Web server traffic.
ms998596.checkbox(en-us,MSDN.10).gif Turn off authentication for anonymous access.
ms998596.checkbox(en-us,MSDN.10).gif Validate user input on the client.
ms998596.checkbox(en-us,MSDN.10).gif Avoid per-request impersonation.
ms998596.checkbox(en-us,MSDN.10).gif Avoid caching sensitive data.
ms998596.checkbox(en-us,MSDN.10).gif Segregate secure and non-secure content.
ms998596.checkbox(en-us,MSDN.10).gif Only use Secure Sockets Layer (SSL) for pages that require it.
ms998596.checkbox(en-us,MSDN.10).gif Use absolute URLs for navigation.
ms998596.checkbox(en-us,MSDN.10).gif Consider using SSL hardware to offload SSL processing.
ms998596.checkbox(en-us,MSDN.10).gif Tune SSL timeout to avoid SSL session expiration.

Deployment Considerations

ms998596.checkbox(en-us,MSDN.10).gif Avoid unnecessary process hops.
ms998596.checkbox(en-us,MSDN.10).gif Understand the performance implications of a remote middle tier.
ms998596.checkbox(en-us,MSDN.10).gif Short-circuit the HTTP pipeline.
ms998596.checkbox(en-us,MSDN.10).gif Configure the memory limit.
ms998596.checkbox(en-us,MSDN.10).gif Disable tracing and debugging.
ms998596.checkbox(en-us,MSDN.10).gif Ensure content updates do not cause additional assemblies to be loaded.
ms998596.checkbox(en-us,MSDN.10).gif Avoid XCOPY under heavy load.
ms998596.checkbox(en-us,MSDN.10).gif Consider precompiling pages.
ms998596.checkbox(en-us,MSDN.10).gif Consider Web garden configuration.
ms998596.checkbox(en-us,MSDN.10).gif Consider using HTTP compression.
ms998596.checkbox(en-us,MSDN.10).gif Consider using perimeter caching.

Patterns and Practices home

.Net 2.0 and Config MaxConnection Values

Filed under: Development — adallow @ 11:15 pm
Tags: ,

Nearly all microsoft.com Web sites have ASP.NET applications that make calls to remote Web service clusters. The maximum number of concurrent remote Web service calls that can be made from a single Web server is determined by the maxConnection attribute of the <connectionManagement> element in the machine.config file. In ASP.NET 1.1, by default the maxConnection value was set to 2. This old default maxConnection value was much too low for sites like microsoft.com that have hundreds of different applications that make remote Web service calls. The result was that ASP.NET requests would queue while waiting for the remote Web service calls to complete. (You can view the number of queued ASP.NET requests via the perfmon counter ASP.NET\Requests Queued.) To enable more calls to execute concurrently to a remote Web service (and thereby improve the performance of applications on the site), we increased the maxConnection value to 40 for our quad processor Web servers. (The general recommended value for maxConnection is 12 times the number of CPUs, but tune this to suit your specific situation.)
In ASP.NET 2.0, however, you no longer need to configure maxConnection manually as it is now automatically scaled and set. This is a result of the new configuration section for the processModel tag in machine.config (for more information about the processModel element, see “processModel Element (ASP.NET Settings Schema))”.

<system.web>
    <processModel autoConfig="true" />
</system.web>
With autoConfig enabled in machine.config (this is the default setting), ASP.NET sets the value of the maxConnection parameter to 12n (where n is the number of CPUs). Enabling autoConfig also causes the following: the maxWorkerThreads parameter and the maxIoThreads parameter are set to 100, the minFreeThreads parameter is set to 88n, the minLocalRequestFreeThreads parameter is set to 76n, and the minWorkerThreads is set to 50.
Prior to making use of autoConfig in ASP.NET 2.0 to automatically scale and set values for maxConnection and the other attributes in the list, be sure to remove any manually set values for these parameters as these values would be used instead of the autoConfig values. This is something to keep in mind when migrating from ASP.NET 1.1 (where maxConnection needed to be explicitly set) to ASP.NET 2.0, where there are defaults.
Again, the autoConfig values for maxConnection and the other attributes listed previously are somewhat arbitrary and may not work for absolutely every instance, but I have found that these limits work well for nearly all microsoft.com applications.
If you decide that you need to tune the maxConnection value manually, be cautious when increasing its value as this can lead to an increase in CPU utilization. This increase is caused by the fact that more incoming requests can be processed by ASP.NET instead of having them wait for their turn to call the Web service. Of course, you should remember that the maxConnection attribute does not affect local Web service calls, only remote calls.
Interesting I came across this code fragment, wonder if it works….
System.Net.ServicePointManager.DefaultConnectionLimit=<your value here>

November 11, 2008

Sticky Sessions, Load Balancing, Failover and Availability

Filed under: Development,Enterprise & Application Architecture — adallow @ 11:21 am
Tags: ,

All HTTP load balancers support “sticky sessions”: Requests in the same session must be forwarded to the same server node unless there is a failover. You must turn on sticky sessions in your setup. In an ideal world, all nodes in a replicated cluster have the same state; thus, the load balancer can forward any request to any node. But in a real cluster, the network and CPU resources are limited. It takes time to actually replicate the state from node to node. Without sticky sessions, the user gets random HTTP 500 errors when the request hits a node that does not yet have the latest replicated state.

fromjboss doco with some minor editing on my part to keep it just at the concept level.

Create a free website or blog at WordPress.com.