LoadRunner-Results analysis/result analyses

LoadRunner is the most important and difficult to understand-the analysis of the test results. The rest of the recording and pressurization tests can be easily mastered by a couple of operations. For Results analysis I used a picture plus text to do an example, I hope we can give you more help by example. This example focuses on multiple users taking over the task at the same time, testing the system's responsiveness, and determining the system bottleneck. Customer demand response time is 1 people take over the time within 5S.

　　2. System resources:

2.1 Hardware Environment:

CPU: Ben Four 2.8E

HDD: 100G

Network environment: 100Mbps

2.2 Software Environment:

Operating system: English windowsxp

Server: Tomcat Service

Browser: IE6.0

System structure: b/S structure

　　3. Adding Monitoring resources

The following example adds some of the most common resource parameters in our usual tests. There are some special resources that are not explained here for the time being. I will add them in the future.

The 5 most commonly used resources in Mercury LoadRunner analysis.

1. VUser

2. Transactions

3. Web Resources

4. Web Page Breakdown

5. System Resources

You can see these resources by selecting "Add graph" or "New graph" in the analysis. There are other resources without data that we don't have to show.

　　

If you want to see more resources, you can leave display only graphs containing data in the lower left corner to be selected. Then select the appropriate point "open graph".

Open Analysis The first thing you can see is the summary report. This shows the analytical summary of the test. Everything. But we don't need to look at each one. Here's what the section means:

Duration (Duration): Learn about the duration of the test process. The testers themselves have a general familiarity with how much of the system has been done during this time period. To determine the duration of the test under the next additional task condition.

Statistics Summary (Statistical Digest): Just about the test data, it does not have much effect on our specific analysis.

Transaction Summary (transaction summary): Understand the average response time average units in seconds.

The rest can not be looked at. It's not very important.
"Note" 51Testing authorized IT168 Exclusive reprint, without express written permission, no person or unit may copy, reprint or mirror the contents of this article, otherwise it will be held liable.

Content navigation

　　4. Analyze meeting Points

In the recording script we usually use the rendezvous point, so since we use the rendezvous point, we need to know when the VUser is set at this point, and what kind of a release process. This is the time to observe the vuser-rendezvous map.

　　

Figure 1

You can see about 3 minutes and 50 of the place 30 users are all concentrated to the start meeting point, the last 3 points, at 7 minutes to start the release of the user, 30 points 9 and 30 users, 18 points 11 and 10 users, the entire process lasted 5 points.

　　

Figure 2

Figure 2 above is a comparison of the meeting point and Average transaction response time.

Note: After opening an analysis, System LR defaults The two curves are not in the same diagram. This needs to be set on its own. The steps are as follows:

Click on the diagram. Right-Select the merge graphs. Then select the graph.3 to be used for comparison in select graph to merge with:

　　

Figure 3

The darker color in Figure 2 is the average response time, the light is the collection point, when the VUser at the meeting point of 1 minutes after the average response time to render the maximum, the visibility of the user's concurrency to the performance of the system is a great test. Let's look at the parameter analysis for the transaction.

　　

Figure 4

This chart includes two data graphs for average Transaction Response time and running VUser. You can see that the vuser_init_transaction (System login) has no effect on the system, VUser reaches 15 When the average transaction response time has a significant increase, that is, the system to achieve optimal performance when the 14 users to allow processing transactions, VUser reached 30 after 1 points, the system response time is the largest, then the maximum response time is to postpone 1 minutes to appear, After the system stabilizes, the transaction response time begins to drop. This time some users have finished the operation. You can also see that you want to control the transaction response time within 10S. The number of VUser cannot exceed 2. It seems difficult to meet the needs of users.

Do one thing sometimes the superiors will ask you how it is done. You'll say it's half done. So how much time do you spend on this half-way? So we want to know that the percentage of transactions completed within a given timeframe depends on the figure below (Transaction Response time ( Percentile)

　　

The circle in the figure indicates that 10% of the transaction response time is around 80S. 80S is not a very small number for the user, and only 10% of the transaction, Khan. Do you think this system performance will be good!

The actual work encountered in the matter is not everything can be done in a short time, for those who need time to allocate the appropriate time to deal with, the uneven time distribution will appear some things take longer, some things short, but we know. LR also provides us with a feature that allows us to understand how much of the transaction response time is? To determine how much of this system we have to pay to improve it.

Transaction Response Time (distribution)-Transaction response times (distribution)

Displays the distribution of time spent executing the transaction in the scenario. If you define acceptable minimum and maximum transactional performance time, you can use this figure to determine whether the server is in an acceptable range.

　　

It is clear that the response time for most transactions is 60-140s. The maximum response time that most customers can accept in the projects I have tested is around 20S. 140S of time! Few people will spend so much time waiting for the page to appear!

By observing the above data table. It is not difficult to see that this system is not ideal in this environment. There is something in the world, and what causes it to be so bad? Let's take a step-by-step analysis.

The reasons for the poor system performance in many ways, we first look at the application. Sometimes I have to admit that LR is really powerful, and that's why I like it. First look at a page subdivision.

　　

An application is composed of many components, the overall system performance is not good then we will thoroughly analyze it. The picture shows all the Web pages involved in the entire test. The Web page breakdown shows the download time for each page. Click the lower left corner of the Web page Breakdown expands, you can see all the properties of the CSS style sheet, JS script, JSP page, etc. included in each page.

Select the page in select page to breakdown.

　　

See figure.

After selecting Http://192.168.0.135:8888/usertasks in select Page to breakdown, you see the two components that belong to it below, and the first row connection and primary Buffer occupy the entire time , then its time-consuming point is here, we have to solve the problem from here.

　　

　　

It's also possible that your program has the longest client time. Or something else, this is based on your own test results. Let's take a look at the CPU, memory. The bottleneck analysis method of hard disk:

First we have to monitor the CPU, memory. The resource condition of the hard disk. The following parameters are given to provide the basis for analysis.
%processor Time (processor_total): The number of processor times consumed by the device. If the server is dedicated to SQL Server, the maximum acceptable limit is 80%-85. That is, the common CPU usage.

%user Time (Processor_total):: Represents CPU-intensive database operations such as sorting, executing aggregate functions, and so on. If the value is high, consider increasing the index, using a simple table join, and horizontally splitting the large table to reduce the value.

%DPC Time (Processor_total):: The lower the better. In multiprocessor systems, if this value is greater than 50% and processor:% Processor time is very high, joining a network card may improve performance and the provided network is already unsaturated.

%disk Time (Physicaldisk_total): Refers to the percentage of the selected disk drive that is busy servicing a read or write request. If the three counters are larger, then the hard drive is not a bottleneck. If only%disk time is larger and the other two are relatively moderate, the hard disk may be a bottleneck. Before you log this counter, run Diskperf-yd in the Windows 2000 command-line window. If the value continues to exceed 80%, it may be a memory leak.

availiable bytes (memory): Number of physical memories. If the value of available MBytes is small (4 MB or less), the total memory on the computer may be insufficient, or a program does not release memory.

Context switch/sec (System): (Instantiating Inetinfo and dllhost processes) if you decide to increase the size of the thread byte pool, you should monitor these three counters (including one above). Increasing the number of threads may increase the number of context switches so that performance does not rise instead of falling. If the context switch value for 10 instances is very high, you should reduce the size of the thread byte pool.

%disk reads/sec (physicaldisk_total): The number of bytes read per second.

%disk write/sec (physicaldisk_total): The number of bytes written per second.

Page FAULTS/SEC: The failure of a process to generate a comparison of the system to determine the impact of this process on the system page failure.

Pages per second: number of pages retrieved per second. The number should be less than one page per second working set: The most recent memory page used by the thread, reflecting the number of memory pages used by each process. If the server has enough free memory, the page is left in the working set, and when free memory is less than a specific threshold, the page is purged from the working sets.

Avg.Disk Queue Length: The average number of read and write requests (queued for the selected disk in the instance interval). The value should be no more than 1.5~2 times the number of disks. To improve performance, you can increase the disk. Note: A RAID disk actually has more than one disk.

Average disk Read/write Queue Length: Refers to the average number of read (write) requests (queued) disk reads/(writes)/s: Amount of disk reads and writes per second on the disk. The sum of the two should be less than the disk device maximum capacity.

Average disk Sec/read: The average time required to read data on this disk in seconds. Average disk Sec/transfer: Refers to the average time required to write data on this disk in seconds.

Bytes Total/sec: The rate at which bytes are sent and received, including frame characters. To determine if the network connection speed is a bottleneck, you can compare the value of this counter with the current network bandwidth to page READ/SEC: The number of physical database page reads issued per second. This statistic shows the total number of physical page reads across all databases. Because of the overhead of physical I/O, the overhead can be minimized by using methods such as larger data caches, smart indexes, more efficient queries, or changing the design of the database.

Page write/sec: (Write page/sec) number of pages written per second for physical database execution.

Content navigation

　　1. Judging the application problem

If the system due to the inefficiency of the application code or the structure of the system is flawed, resulting in a large number of context switches (context switches/sec display the number of contexts to switch too high) then it will consume a lot of system resources, if the system throughput is reduced and the CPU usage is high, And this phenomenon occurs when the switching level is above 15000, which means that the context switch times too high.

　　

From the overall view of the picture. The context switches/sec changes little, the slope of the throughout curve is higher, and at this time the contextswitches/sec has exceeded 15000. The program still needs to be further optimized.

　　2. Determine CPU Bottlenecks

If the queue length shown by the processor queue lengths remains constant (>=2) and the processor utilization%processortime exceeds 90%, there is a good chance that the processor bottleneck is present. If you find a processor queue The length of the queue is more than 2, and the processor utilization has been low, perhaps more to solve the processor blocking problem, where the processor is generally not a bottleneck.

　　

%processor time average is greater than 95,processor queue Length is greater than 2. You can determine the CPU bottleneck. The CPU is no longer sufficient for the program. Need to expand.

　　3. Determine memory leak issues

Memory issues primarily check the application for memory leaks, and if a memory leak occurs, the values of the Process\Private bytes counter and the Process\Working set counter tend to rise, while avaiable The value of the bytes is reduced. The memory leak should be tested by a long time, which is used to investigate the application response when all memory is exhausted.

　　

You can see that the program does not have a memory leak. The memory leak problem often occurs when the service is running for a long time, and the memory is slowly exhausted because some programs do not release the memory. It is also a reminder of the focus on system stability testing.

Attachment:

CPU Information:

Processor\% Processor time for processor usage.

You can also choose to monitor processor\% User time and% Privileged time for more information.

The Server work queues\ Queue Length counter displays the processor bottleneck. A continuous queue length of more than 4 indicates processor congestion may occur.

System\ Processor Queue Length is used for bottleneck detection by using process\% Processor time and process\ working Set

Process\% Processor The total processor time for all threads on each processor.

Hard Drive information:

Physical Disk\% Disk time

Physical Disk\ Avg.Disk Queue Length

For example, include Page reads/sec and% Disk time and Avg.Disk Queue Length. If the page read operation rate is low and the value of% Disk Time and Avg.Disk Queue length is high, there may be a disk bottle diameter. However, if the queue length increases at the same time that the page read rate is not reduced, there is insufficient memory.

Physical Disk\% Disk time

Physical Disk\ Avg.Disk Queue Length

For example, include Page reads/sec and% Disk time and Avg.Disk Queue Length. If the page read operation rate is low and the value of% Disk Time and Avg.Disk Queue length is high, there may be a disk bottle diameter. However, if the queue length increases at the same time that the page read rate is not reduced, there is insufficient memory.

Observe the value of the Processor\ interrupts/sec counter, which measures the speed of service requests from input/output (I/O) devices. If the value of this counter increases significantly and system activity does not increase correspondingly, there is a hardware problem.

Physical Disk\ disk reads/sec and disk writes/sec

Physical disk\ Current Disk Queue Length

Physical Disk\% Disk time

Logicaldisk\% Free Space

When you test disk performance, log performance data to another disk or computer so that the data does not interfere with the disk that you are testing.

Additional counters that may need to be observed include physical disk\ Avg.Disk Sec/transfer, Avg.diskbytes/transfer, and Disk bytes/sec.

The Avg.Disk Sec/transfer counter reflects the time that the disk took to complete the request. A higher value indicates that the disk controller has repeatedly retried the disk because of a failure. These failures increase the average disk transfer time. For most disks, the average transfer time for a higher disk is greater than 0.3 seconds.

You can also view the value of the Avg.Disk Bytes/transfer. A value greater than KB indicates that the disk drive generally works well, and a lower value is generated if the application is accessing the disk. For example, an application that randomly accesses a disk increases the average disk Sec/transfer time because random transfers require additional search time.

Disk BYTES/SEC provides the throughput rate of the drive system.

Determine workload balance to balance the load on the network server, you need to know how busy the server disk drives are. Use the physical Disk\%disk time counter, which displays the percentage of drive activity times. If the% Disk time is higher (more than 90%), check the physical disk\ Current disk Queue Length counter to see the number of system requests that are waiting for disk access. The number of wait I/O requests should remain at 1.5 to twice times greater than the number of spindles that make up the physical disk.

Although a redundant array of inexpensive disks (RAID) device typically has multiple spindles, most disks have one spindle. A hardware RAID device appears as a physical disk in System Monitor, and a raid device created by software appears as multiple drives (instances). You can monitor physical Disk counters for each physical drive (not RAID), or you can use _total instances to monitor data for all computer drives.

Use the current disk Queue Length and% Disk Time counters to detect bottlenecks in the disk subsystem. If the value of the current disk Queue Length and% Disk time are always high, consider upgrading the disk drive or moving some files to another disk or server.

LoadRunner-Results analysis/result analyses