.net性能测试和优化2 Profiling和提高的一些参考

Application Profiling

Using profiling tools to look for potential bottlenecks during development can significantly reduce the number of problems that show up later. With the right tools and training, this can become a regular part of the development process without adding too much overhead.

Profilers retrieve performance and memory information from .NET applications in one of three ways:

• Sample based

The application function call stack is periodically recorded to give a low overhead, but equally low resolution analysis.

• Events based

The Common Language Runtime can be configured to send notifications to specific profiler DLLs. Key information on function execution, CPU, memory, and garbage collection can be collected using this mechanism.

• Instrumentation

Instrumentation code that measures the application is added to it at runtime, which can give very detailed and accurate results, but also comes with a high overhead.

http://blogs.msdn.com/b/tvoellm/archive/2007/08/02/what-is-the-difference-between-sample-and-instrumentation-based-profilers.aspx

When to use sample vs instrumenation based profilers:

Sample based - Good for CPU bound problems,

Instrumentation based profilers - Good for I/O, idle wait, memory, ...

Performance profiling

Performance profiling is all about discovering which parts of your application consume a disproportionate amount of time or system resource.

Memory profiling

Checking that an application doesn't have memory leaks, and that it uses memory efficiently, together with fixing any issues found, will improve its overall stability and performance.

工具

CLRProfier

Microsoft Visual Studio 2008 profiling tools

Red Gate's ANTS Memory and Performance Profilers

Microfocus DevPartner Studio Professional 9.1

SQL Profiler 2005/2008

分析

Performance analysis
High call count	Functions with very high call counts should be treated with suspicion and investigated. Often the high call count is valid, but sometimes it's due to an error in event handling, and can be a major source of unintended processing	Using the call graphing facility of your performance tool, it should be possible to trace back to where the calls to the function originate, and decide if it is acceptable behaviour. It's a very quick and easy check, and a very quick optimization if a problem is found. I have actually lost count of the number of times I have found this issue in live code!
Slowest function excluding child calls	This is the slowest function where the body of the function itself is responsible for the time. It includes time spent calling .NET framework functions, but excludes time spent calling other source code functions. In other words, it's answering the question, "What's the slowest function we have written?"	Identify the slowest functions excluding child calls and then, if available, look for the slowest code lines and determine if they are optimizable. You will often see slow lines waiting for database and web service calls to return.
Slowest function including child calls	This is the slowest function where the total cost of the functions, including time spent into calls to child functions (we have written), is accounted for.	Use your tool's call graph facility to explore the slowest part of the call tree
Functions with high CPU utilization	Any function with high CPU utilization is a prime candidate for optimization, as high resource demands can be a key bottleneck.	Identify the most CPU-intensive lines of code within the function and determine if there are workable optimizations that may apply.
Functions with Wait time	Functions with Wait time can indicate performance problems in other application layers, or problems with thread locking	Identify which resource the function is waiting for, e.g. database or web service, then investigate the cause of the contention on that layer.
Functions generating disk activity	A function generating disk activity needs to be investigated further, as it is demanding resources and is therefore a potential bottleneck	Make sure the disk activity is necessary, particularly if this is a server application. Even if it is necessary, try to find an alternative if possible.
Functions generating network activity	A function generating network activity needs to be investigated further as another potential bottleneck.	Make sure the network activity is valid and not an artifact left behind from prototyping or developer testing. Ensure that the number of times this network activity occurs is as low as possible, to reduce the effect of latency. If possible, get more data in one hit
Memory analysis
Memory leak detection	Finding memory leaks is all about identifying objects that are allocated but never garbage collected
Excessive memory usage		Reducing the overall memory footprint
Inefficient allocation and retention
Large Object Heap fragmentation

Common Areas for Performance Improvement

数据库	连接：连接是昂贵的资源 缓存： Asp.net Cache: 如SqlCacheDependency AppFabric： cache farm Indexing Database Engine Tuning Advisor O/R框架 动态SQL的影响，separate views and functions, or perhaps a dedicated stored procedure
Reflection	Reflection is a very powerful mechanism 恰当的使用
String manipulation	StringBuilder和String的区别
Cryptographic functions	加密强度和性能
Network call latency	Protocol Size of payload Serialization/deserialization Chatty vs. chunky： 请求的次数
Synchronous vs. asynchronous
Web	页面绑定的信息http://localhost:***/Trace.axd OutputCache web.config <system.web>下的一些配置项 <compilation debug="false"> <trace enabled="false"/> <deployment retail="true"> <httpHandlers>