Performance of an application is very
important for a multi-user application. Performance is not only the speed of
execution; it includes the load and concurrency aspects. Performance Test is an
answer for the following questions
can we ensure that our new application will support the expected user
to avoid the issues which will arise only in real load conditions?
to find the response time?
to plan the capacity of the servers?
Visual Studio is one of the tools used
for Performance Test. Visual Studio Test edition or Visual Studio 2010 Ultimate
provides the support for test automation.
This will be the third part of a series of articles.
I: Web Test and Customization
Part II: Load Test,
RIG and Load test terminologies.
Part III: Performance Counters, Load Test Result Analysis.
Performance counters are predefined or custom counters used
to measure the performance of a system. Performance test result analysis fully
depends on the performance counters captured as part of the test. So for a
better performance result and better analysis, we need to first understand the
important counters related to each server.
We can capture the counters either using the Performance
Monitor discussed in this article
or using the Visual studio itself. For capturing the corresponding server
counters, add the servers to the computers section in Load test.
Add Computers for collecting Performance Counters
Right click on Counter Set Mappings under the Run Settings
of Load test and select Manage Counter Set option.
This will open the Manage Counter Sets window, where we can
add the computers. Add the systems and select corresponding counter sets.
When the load test executes, we can observe the counters
corresponding to each system in Visual Studio itself.
Adding Counters to Performance Monitor
Setting Performance Monitor to capture the counters is
discussed in this article. If you use the performance monitor to capture the
counters, then we need to ensure to start the custom counter set before the
load test start and end the same after the load test completes. Also need to
merge the results from various servers and generate the reports.
Depends on the server and application hosted on the same, we
have to capture the counters. For example, the counters required for a database
server will be different from that of a web server. Also we have generic
counters required for every server like the processor utilization or memory
utilization, etc. In this section, we will discuss about the Generic counters,
important counters required for an application server, counters required for a
database server. Here, we will discuss few of the important counters, but not
\Processor(*)\%Processor time - This counter measure the
processor utilization. Capture this counter from all servers and measure the
average utilization, In an Idle situation, processor utilization should be less
\Process(*)\Private Bytes - Indicates the memory
allocated to this process in terms of bytes. This indicates the memory usage of
\Network Interface\Bytes Received/sec, \Network
Interface\Bytes Sent/sec, \Network Interface\Bytes Total/sec - these three
counters determines the network usage of the server.
ASP.Net web Application Server Counters
\.Net CLR Data\ - This counter group contains counters
associated with number of pooled connections, number of failed connect attempts
and number of connection pools associated with specific process running on the
\.Net CLR LocksAndThreads\ - this counter group contains
information on number of physical and logical threads and any contentions occurred.
\.Net CLR Memory\ - this counter collection includes the
number of Gen 0, 1 and 2 collections and heap sizes. This determines the
garbage collection rates and in turns the memory management in the application.
\.Net Memory Cache4.0\ - this counter group is for
understanding the caching implementation in your application.
\ASP.Net Applications\ - this counters determine the overall
request processing and application management. How many requests processed,
rejected, queued and disconnected, cache hits and misses, errors,
authentication failures, Output cache entries and misses, sessions abandoned and
active, transactions committed and aborted.
Database Server Counters
\Database\ - General database related counters like
database cache size, I/O database reads and writes, Pages converted and records
converted. SQL Server specific counters are defined in separate counter groups.
\SQLAgent:Jobs\ - this group contains counters to
understand the status of the jobs running in SQL Server. These indicate how
many jobs are active, failed, queued and successfully executed.
\SQLServer:Locks\ - this counter determines how many
dead locks occurred in the application execution.
Before discussing about the counters and how to interpret
them, we need to look into the various terms associated with a performance
Most of the performance test is done to understand the
response time of an application in a given load. If an application is not
completed its performance test, then the response time for an expected user
load may not be defined.
Response time is the time taken by a web page or a
transaction to respond to the user. 8sec is the standard maximum response time
for a web page. If the page is having lot of images or video clips, it may take
more time to load. For better usage, we can load the page in progress using
Asynchronous calls and Ajax. If the response time is very high, the user
experience will be low and the usage of the application may affect it. For
decreasing the response time at the same time keeping the rich user interface
is one of the challenges.
Throughput is the number transactions or inputs handled by
the server per second. This indicates how much load or requests the server can
handle at once. Depends on the throughput and response time requirements we may
plan the clustering of servers.
Resource utilization includes the servers’ processor, memory
and network utilizations. How much the application utilizing the server
resources determine, whether we can go with a single server or need to have
multiple servers or not.
These are three major terms or measures we use in
performance test. Apart from these measures, we have network time, latency
time, request time, test mix, load mix, etc. We will discuss later on the
different terms associated with a performance test.
Now, we have the required counter data and the performance
data like response time and throughput. Performance result analysis for
different scenarios cannot be explained in one or two documents. Depends on the
data we receive as a result of performance test, the analysis will vary.
For example, consider you are getting very high response
time with good resource utilization. This simple means, the high response time
is not due to any resource issue, it may be due to your SQL part or due to
front end code. Look into the SQL counters and determine, whether the
particular page is making any database calls which yields lot of reads, writes
and CPU cycles. If so, then the issue is with database query or stored
procedure. Once, we narrow down the issue to database level, and then we can
use the database tools like SQL Execution plan or Database engine tuning
advisor to understand the issue and fix the same.
If the issue is with application code, then we need to
examine, whether the issue is due to any cache issues, images, threading
issues, connection pooling, etc.
We will discuss more on result analysis using some sample
scenarios in next article.
If you like this article, subscribe to our RSS Feed. You can also subscribe via email to our Interview Questions, Codes and Forums section.