Performance Test Results Analysis report

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. —————————————— is to do a brief summary of the various diagrams ———————————— 1, analysis of the summary 2, VUser figure: mainly include the VUser diagram, VUser outline diagram, 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 through the total number of transactions per second, can be applied to the overall performance of a certain comparison and description.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 analysis in LoadRunner. The following are some references: 1, think time during the recording script, because of the number of reasons for the operation will automatically add some thinking time statements between the start and end of the transaction, in the playback script, if the thinking time is recorded in the replay, then the thinking time will be recorded in the process of transaction response time, Statistics that affect 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 figure of the set 3, analysis of transactional performance analysis scenarios or session steps run from the average transaction response time diagram and the transactional Energy summary diagram. 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 in order to determine the problem and to understand why the transaction response time is preserved during the scenario or session step execution, need to subdivide the transaction and analyze the performance of each page component 4, use the page subdivision chart to use the page subdivision chart, You can search the average transaction response time graph or the transactional energy profile to see the download time for each page component in a transaction. Note: Only in the run scenarioor the page segmentation feature is enabled before the session steps can be achieved. 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 the most closely related to the problem of a number of measures, and then look at the measurement of the corresponding resource map to determine the cause of the system bottlenecks 6, compare the results of different scenarios each time to fine-tune the system and solve other performance bottlenecks, 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. —————————————————— Example Analysis —————————————— 1, identify server issues 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, fine-tuning 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 encryption is changed from 1024 to $) d, do not use SSL for transition. 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 personal accumulation of more material, to test the verification ...