Return to HomePage

---

How To: Identify Bottlenecks in Web Applications

Source: http://msdn.microsoft.com/library/en-us/dnpag/html/scalenetchapt17.asp
J.D. Meier, Srinath Vasireddy, Ashish Babbar, Rico Mariani, and Alex Mackman


You need to identify bottlenecks caused by poor design or implementation early in the application life cycle. Bottlenecks that cannot be optimized or tuned need to be identified as constraints during the design phase of the life cycle, so that they can be factored in the design to minimize the impact on performance.
What Are Bottlenecks?
A bottleneck is the device or resource that constrains throughput. Most of the time, performance bottlenecks in your application relate to resource issues that may include server resources such as CPU, memory, disk I/O, and network I/O or other external resources such as available database connections or network bandwidth.
Bottlenecks vary from layer to layer, based on the server role:
* Web/Application server. Some common causes of bottlenecks include inefficient session and state management, thread contention, long-running calls to a Web service or a database, and chatty interfaces.
* Database server. Some common causes for bottlenecks include poor logical database design such as bad table design, improper normalization of tables, inefficient indexes on tables, and badly partitioned data across tables. Other causes include inefficient queries, inappropriate isolation levels used by transactions in queries, and inefficient stored procedures.
How to Identify Bottlenecks

The first step in identifying bottlenecks is to know the different tests and measurements that you must run to simulate varying user loads and access patterns for the application. The following measurements help you to expose bottlenecks and isolate areas that require tuning:
* Measure response time, throughput, and resource utilization across user loads.
* Measure metrics that help you capture a more granular view of your application.

Measure Response Time, Throughput, and Resource Utilization Across User Loads
These metrics help you identify whether you are moving toward or away from your performance goals with each iteration through the tuning process. These also give you a rough idea as to which resource is the first bottleneck for the application, and on which server the bottleneck occurs.
Analyzing Response Time Across User Loads
When you measure response times with varying number of users, watch for a sharp rise in response time. This rise is the point of poor efficiency, and performance only degrades from this point onward, as shown in Figure 17.3.

{Insert figure: CH17 – Response Time vs User Load.gif}
Figure 17.3
Response time vs. user load
Measuring Throughput Across User Loads
When you measure throughput across user loads, watch for the peak levels of throughput. At the point where throughput starts to fall, the bottleneck has been hit. Performance continues to degrade from this point onward. An example is shown in Figure 17.4.

{Insert figure: CH17 – Throughput vs User Load.gif}
Figure 17.4
Throughput vs. user load
Analyzing Resource Utilization Across User Loads
Analyze resource utilization levels across linearly increasing user loads. See whether the resource utilization levels increase at a sharper rate as new users are added and more transactions are performed. Figure 17.5 shows a linear utilization level for increased user load.

{Insert figure: CH17 – Utilization vs User Load.gif}
Figure 17.5
Utilization vs. user load
Measure Metrics that Help You Capture a More Granular View of Your Application
Using input from the coarse-grained monitoring of your performance objectives mentioned earlier, you can add additional counters during subsequent iterations of the tuning process.
Continuing with the example introduced earlier, if you are performing a remote database call, you can measure the time taken by the database call to complete. Monitor the metrics related to indexes, locks, number of tables scanned, resource utilization levels, and so forth on the database to identify the reason why the query is taking a long time to execute.
More Information
For more information about measuring throughput, load testing, and generating user load, see Chapter 15, "Measuring .NET Application Performance" and Chapter 16, "Testing .NET Application Performance."

---

Return to HomePage