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