So let us take advantage of performance testing/tuning

原文地址：http://www.codeproject.com/useritems/ASPNET_and_IIS_60.asp

Unfortunately where to start a testing and tuning process can be driven by who has the biggest issues first.  Would it be the Server Admin, the Architect, the Developer, or the user who experiences a slow-down?  If there is a large out-cry from users, or you expect traffic to rapidly expand with a new roll-out, you may not want to be caught off guard by not being proactive.

Possibly all of you may want to go through some ASP.NET Performance Checklists with your staff:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/ScaleNetCheck03.asp

A short list of topics from the above link include:

Design Considerations Consider security and performance. Partition your application logically. ...	Threading Tune the thread pool by using the formula to reduce contention. Consider minIoThreads and minWorkerThreads for burst load. ...	Resource Management Do not cache or block on pooled resources. Pool resources. ...	Pages Trim your page size. Enable buffering. ...
Server Controls 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. Cache the right data. Use kernel caching on Microsoft® Windows Server™ 2003. ...	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. Do not store single-threaded apartment (STA) COM objects in application state.	Session State Prefer basic types to reduce serialization costs. Disable session state if you do not use it. Avoid storing STA 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 Modules 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 HtmlTextWriter when building custom controls.	Exception Management Implement a Global.asax error handler. Monitor application exceptions. Set timeouts aggressively. ...	COM Interop Use ASPCOMPAT to call STA COM objects. Avoid storing COM objects in session state or application state. Avoid storing STA components in session state. ...	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. ...
Security Considerations Constrain unwanted Web server traffic. Turn off authentication for anonymous access. Validate user input on the client. Avoid per-request impersonation. Avoid caching sensitive data. Segregate secure and non-secure content. Only use Secure Sockets Layer (SSL) for pages that require it. Use absolute URLs for navigation. Consider using SSL hardware to offload SSL processing. Tune SSL timeout to avoid SSL session expiration.		Deployment Considerations Avoid unnecessary process hops. Understand the performance implications of a remote middle tier. Short-circuit the HTTP pipeline. Configure the memory limit. Disable tracing and debugging. Ensure content updates do not cause additional assemblies to be loaded. Avoid XCOPY under heavy load. Consider precompiling pages. Consider Web garden configuration. Consider using HTTP compression. Consider using perimeter caching.

Of course you are going to need a "MS Web Application Stress Tool" for some testing: http://www.microsoft.com/technet/archive/itsolutions/intranet/downloads/webstres.mspx

Then you can begin to chart out and then tune your .NET applications performance: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt16.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt17.asp

Then you can begin to take this information and compare it against the many ASP.NET How To documents:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenethowto.asp

Topics include:

1. "How To: Improve Serialization Performance"
2. "How To: Monitor the ASP.NET Thread Pool Using Custom Counters"
3. "How To: Optimize SQL Indexes"
4. "How To: Optimize SQL Queries"
5. "How To: Page Records in .NET Applications"
6. "How To: Perform Capacity Planning for .NET Framework Applications"
7. "How To: Scale .NET Applications"
8. "How To: Submit and Poll for Long-Running Tasks"
9. "How To: Time Managed Code Using QueryPerformanceCounter and QueryPerformanceFrequency"
10. "How To: Use ACT to Test Performance and Scalability"
11. "How To: Use ACT to Test Web Services Performance"
12. "How To: Use Custom Performance Counters from ASP.NET"
13. "How To: Use the CLR Profiler"
14. "How To: Use EIF"
15. "How To: Use the SQL Profiler"
    
    

See also http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/webapp/iis/iis6perf.mspx

1) So let's try some things out and retest after implementation.

GZip - IIS 6.0: While the benefit will be for Firefox and IE 6.0 browser users for now it is worth your attention.  Do note though that Gzip gains are in bandwidth and as gains in "perceived" speed of page loads. It could also help reduce the amount of bytes sent by the server, so for high volume servers this could yield more sizable results.  Also note CPU utilization spikes may result.

For more details see:
http://www.microsoft.com/resources/documentation/iis/6/all/proddocs/en-us/ref_mb_hcdodynamiccompression.mspx

Check your Scalability and work with GZip Headers:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt04.asp

The original specs for GZip are also sometimes useful:
http://www.ietf.org/rfc/rfc1951.txt?number=1951 and http://www.ietf.org/rfc/rfc1952.txt?number=1952

Edit the Metabase

WARNING: If you edit the metabase incorrectly, you can cause serious problems that may require you to reinstall any product that uses the metabase. Microsoft cannot guarantee that problems that result if you incorrectly edit the metabase can be solved. Edit the metabase at your own risk.

NOTE: Always back up the metabase before you edit it.

To enable IIS 5.0 to compress .aspx pages, follow these steps: 1. Open a command prompt.
2. Type net stop iisadmin, and then press ENTER.
3. Type cd C:\InetPub\adminscripts, and then press ENTER.
4. Type the following, and then press ENTER:
CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcScriptFileExtensions "asp" "dll" "exe" "aspx"
5. Type the following, and then press ENTER:
CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcScriptFileExtensions "asp" "dll" "exe" "aspx"
6. Type net start w3svc, and then press ENTER. ¹

See http://support.microsoft.com/?id=322603 for more information and for other issues to help you mitigate issues.

Then see http://www.dotnetdevs.com/articles/IIS6compression.aspx by Brad Wilson for further instructions and a decent trace tool.

Enabling HTTP Compression
If your server generates a large volume of dynamic content, consider whether the additional processing cost of HTTP compression is one that you can reasonably afford. If the % Processor Time counter is already 80 percent or higher, enabling HTTP compression is not recommended.

To test HTTP compression

To establish a baseline, use System Monitor to log the % Processor Time counter of the Processor object over several days. This counter has a total instance and a separate instance for each processor in the system. (If your server has more than one processor, you should watch the individual processors as well as the total to discover any imbalance in the workload.) Additionally, you should log the Bytes Sent/sec counter of the Network Interface object.
Enable compression and continue to log the value of these counters for an extended period, preferably for several days, so you have a good basis for comparison.
Compare the values with and without compression.
Note If you see signs of blocking or bottlenecking during the test, you should promptly stop the test. A significant drop in the value of either counter indicates that performance with compression enabled has decreased relative to performance without compression enabled.

Important You must be a member of the Administrators group on the local computer to perform the following procedure (or procedures), or you must have been delegated the appropriate authority. As a security best practice, log on to your computer using an account that is not in the Administrators group, and then use the Run as command to run IIS Manager as an administrator. From the command prompt, type runas /user:administrative_accountname "mmc %systemroot%\system32\inetsrv\iis.msc".

To enable HTTP compression

1. In IIS Manager, expand the local computer, right-click the Web Sites folder, and then click Properties.
   
2. Click the Service tab, and in the HTTP compression section, select the Compress application files check box to compress application files.
   
3. Select the Compress static files check box to compress only static files for transmission to compression-enabled clients.
   
4. In the Temporary directory box, type the path to a local directory or click Browse to locate a directory. Compressed files are kept in this temporary directory. The directory must be on a local drive on an NTFS-formatted partition. The directory cannot be a compressed directory and should not be shared.
   
5. Under Maximum temporary directory size, click a folder size option. If you click the Limited to (in megabytes) option and enter a number in the text box next to it, IIS automatically cleans up the temporary directory according to a "least recently used" rule when the set limit is reached.
   
6. Click Apply, and then click OK. ²

http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/qos_utilbandwdth.asp

2) Caching, Threads, and SSL- They gave you more in IIS 6.0 so why not use it and tweak it? (Some of the "Highlights".)

"Windows Server 2003 and IIS 6.0 provide kernel caching. ASP.NET pages can automatically benefit from the IIS 6.0 kernel cache. Kernel caching produces significant performance gains because requests for cached responses are served without switching to user mode." ³

---

Recommended Threading Settings for Reducing Contention used when You have available CPU. Your application performs I/O bound operations such as calling a Web method or accessing the file system. The ASP.NET Applications/Requests In Application Queue performance counter indicates that you have queued requests.
Configuration setting	Default value (.NET Framework 1.1)	Recommended value
maxconnection	2	12 * #CPUs
maxIoThreads	20	100
maxWorkerThreads	20	100
minFreeThreads	8	88 * #CPUs
minLocalRequestFreeThreads	4	76 * #CPUs

---

Trim Your Page's "K" size to regain bandwidth

Processing large page sizes increases the load on the CPU, increases the consumption of network bandwidth, and increases the response times for clients. Avoid designing and developing large pages that accomplish multiple tasks, particularly where only a few tasks are normally executed for each request. Where possible logically partition your pages.

To trim your page size, you can do one or all of the following:

• Use script includes for any static scripts in your page to enable the client to cache these scripts for subsequent requests. The following script element shows how to do this.