LoadRunner Result Analysis

LoadRunner Result Analyzer (hereinafter referred to as analysis or analysis module) is a stand-alone module, it can transform test results and monitoring data into database data, for the benefit of analytical processing. Testers can select the icons of interest in the analyzer, analyze the test results and monitoring data by merging graphs, cross graphs and automatic correlation, to determine the performance bottleneck and its causes. Finally, the parser can automatically generate performance reports in HTML or Word format based on the interested part of the tester's selection, which can be presented as a performance reference for Fujian, along with performance test reports.

After the test is finished, the LoadRunner controller can automatically collect the test results from the pressure generator and, together with the monitoring data, generate the result data and save it in the set run results directory.

When the analyzer starts, if the pressure generator is on a remote machine and does not choose to collect the data automatically, the test result data is collected first. Otherwise, the run results file opens, the resulting file is processed, imported into the Microsoft Access database, and then automatically opens some result analysis charts according to the settings template.

—————————————— now make a summary of the various diagrams ————————————

1. Analysis Summary

2, VUser chart: mainly includes the VUser diagram, VUser outline diagram, the collection diagram.

This diagram can be used to determine the vuser load on a server in any given environment. By default, this figure shows only vuser that have a status of run. To see other vuser states, set the filter criteria to the desired state (^_^ ^_^ I haven't found a place to set up the filter yet).

3. Transaction diagram: After you run a scenario or session step, you can use one or more transaction diagrams to analyze the transactions that are performed during the test. The transaction diagram includes the average transaction response time chart, the number of transactions per second, the total number of transactions per second ...

3.1, the average transaction response time chart: For each way, this diagram will be displayed in a different way. About the choice of granularity, the difference between the data ...

Note: By default, only transactions that have been passed are displayed.

You can compare the average transaction response time chart with the running VUser diagram to see how the number of running VUser affects the transactional energy time. For example, if the average transaction response time chart shows a gradual improvement in performance time, you can compare it to a running VUser diagram to see whether performance time has been improved due to reduced vuser load.

If you define a minimum and maximum transaction response time that you can accept, you can use clay to determine whether server performance is in an acceptable range.

3.2, the total number of transactions per second

By the total number of transactions per second, the overall performance of the application can be compared and explained. However, the total number of transactions per second is affected by a number of factors, including step interval time, thinking time, and so on.

3.3. Transaction response time (load) diagram: A combination of a running VUser graph and an average transaction response time graph that indicates the transaction response time, which is related to the number of vuser that are running at any given time in the scene or session step. This diagram helps testers see the overall impact of the vuser load on response time, and is more useful for analyzing scenarios or session steps that have a variable load.

3.4. Transaction response Time (percentage) Figure: This diagram helps testers analyze the percentage of transactions that are performed within a given time span. This diagram can help testers determine the appropriate percentage of transactions to determine whether the system's performance standards are met. Typically, you need to determine the percentage of transactions within an acceptable response time range. The maximum response time can be very long, but if most transactions have acceptable response times, the entire system is still applicable.

———————— to Be Continued ——————————

I was hurt. I just wrote something to save when the hint contains taboo words, hind legs when everything lost ...

Add: Web Resource map, Web page subdivision chart, system resource diagram, merging diagram, cross result graph.

———————————————— Analysis and processing ——————————————————

How to do some analytical processing in the LoadRunner. The following are some references:

1. Thinking time

During the recording of the script, because many of the reasons for the operation result in the automatic addition of some thinking time statements between the start and end of the transaction, when the reflection time is recorded in the playback script, the thinking time is recorded in the transaction response time, which affects the statistics of the transaction response time.

To avoid this, one way is to manually adjust the script after recording it, move the thinking time beyond the start of the transaction, or remove the think time by configuration in the test Results Analyzer.

2, the setting of the diagram

3. Analyze transaction performance

The analysis scenario or session step operation should begin with an average transaction response time chart and a transactional energy summary graph. Using a transactional energy summary diagram, you can determine which transactions are responding over a long period of time during the execution of a scene or session step. Using the average transaction response time chart, you can view the behavior of a transaction that has a problem during the run, every second.

Question: Which transactions have the longest response time. The response time for these transactions is long during the entire execution of a scene or session step or only at a particular time

To identify the problem and to understand why the transaction response time is preserved during this scenario or session step execution, you need to subdivide the transaction and analyze the performance of each page component

4. Use of Web page subdivision chart

With a Web page subdivision, you can search the average transaction response time map or a transactional energy profile to see the download time for each page component in a transaction. Note: This can only be achieved if the page segmentation feature is enabled before the scenario or session step is run.

Question: Which page components are the cause of the too long transaction response time. Whether the problem is related to the network or server.

5. Use Automatic association: Find several metrics that are most closely related to the problem, and then review the corresponding resource graph to determine the cause of the system bottlenecks

6, compare the results of different scenes

Each time you fine-tune your system and troubleshoot other performance bottlenecks, you should run the same load again to verify that the problem is resolved and that no new performance bottlenecks are being created. After several load tests are performed, you can compare the initial results with the final results.

7, generate the report: LR can generate HTML format, Word format, Crystal Report format.

—————————————————— Case Analysis ——————————————

1, identify the server problem

Web site performance problems can be caused by a number of factors. But about half of the performance problems are caused by Web, Web application, and database server failures. The risk of performance problems for a * * Station with a large dependency on the database operation is particularly high.

Common database problems include inefficient index design, segmented databases, outdated statistics, and imperfect application design. Therefore, database system performance can be provided by using smaller result sets, automatically updating data, optimizing indexes, often compressing data, executing queries or locking timeouts, using shorter transactions, and avoiding application deadlocks.

In 20% of the load tests, Web and Web application servers are the cause of performance bottlenecks. Bottlenecks are usually caused by improper server configuration and insufficient resources. For example, problematic code and DLLs may use almost all computer processing time (CPUs) and cause performance bottlenecks on the server. Similarly, physical memory capacity limits and improper server memory management can easily lead to server bottlenecks. Therefore, check the server's CPU and physical memory before investigating other reasons for the low performance of the Web or Web application service.

Ways to improve the performance of secure Web sites are:

A, make subtle adjustments to SSL and HTTPS services based on application type.

b, use the SSL hardware accelerator, such as the SSL accelerator device and the accelerator card.

C, change the security level based on the sensitive level of the data (the key length to be used for public key cryptography changes from 1024 to 512)

D, do not transition using SSL. Those pages with lower data sensitivity should be redesigned to use regular HTTPS.

2, identify network problems

When the load increases significantly but does not have a significant impact on the task server-side components, you can usually identify the network bottleneck. Using the * * Chart, you can determine whether the network is a real bottleneck.

3, identify the database server problem

Here the personal accumulation of more material, to test the verification ...