How to locate performance bottlenecks in Performance Testing

What is the concept and basic purpose of Performance Testing? I think everyone knows it clearly and I will not elaborate on it. In short, performance testing is only a method in the testing process, it helps us to run our functions better. If function testing is available, easy to use, satisfying requirements, and intended for use, performance testing is nothing more than making these goals smoother. No professional concept

What is the concept and basic purpose of Performance Testing? I think everyone knows it clearly and I will not elaborate on it. In short, performance testing is only a method in the testing process, it helps us to run our functions better. If function testing is available, easy to use, satisfying requirements, and intended for use, performance testing is nothing more than making these goals smoother. There is no professional concept, and there are only two words: easy to use!

Therefore, in the process of performance testing, a transitional task is to locate the problems in the execution process, locate the functions, and locate the load, the most important thing is, of course, the "bottleneck" mentioned in the question. It is not deeply exposed to performance tests, but not experts. The bottleneck is caused by the following aspects:

• 1. network bottlenecks, such as bandwidth and traffic.
• 2. Application Service bottlenecks, such as basic middleware configuration and CACHE
• 3. System Bottleneck: Application Server, database server, and client CPU, memory, hard disk, and other configurations
• 4. Database bottleneck. Taking ORACLE as an example, some default parameter settings in SYS
• 5. Application bottlenecks,

There are few network bottlenecks, but they are not none. First, let's look at the network congestion, network disconnection, bandwidth occupation by other resources, speed limit, and so on, what is the situation of an application or system? For the WEB, it is nothing more than timeout, HTTP400, 500 and other errors. For some client programs, it may also be timeout, disconnection, and server delivery, A more obvious case where the information returned by the server cannot be obtained is that the transaction commit is slow. If the encapsulated transaction code is not perfect, the general error is that the data commit is incomplete, or repetitive submission due to final network issues and code defects. In this case, we must consider the network bottleneck and how to optimize the network when there is a problem. It is necessary to optimize the interaction code or interfaces.

The positioning of Application Service bottlenecks is complicated and difficult to learn. However, there are many materials available for reference on the Internet. Generally likeMcAt, weblogic, and so on. There are default settings andArchitectureAnd maintenance personnel to test and debug some values, these values can generally meet the needs of the program release, do not have to make too many settings, maybe we know the most basic is JAVA_OPTS settings, maxThreads,TimeWe use tools such as LR, Jemeter, and webload to perform performance tests, especially for application services. If the application service has a bottleneck, generally, we set log4j. properties, logs are recorded. Then, based on the log, further determine the application service problems

System Bottleneck. Although this positioning is complicated, there are many experience experiences from our predecessors. I don't want to explain it. I believe that we can also get some metric values from the performance calculator using LR, plus nagios, cacti clearly shows which resources are sufficient and which resources are obviously insufficient. However, the general cause of system bottlenecks is the application itself. The Analysis and positioning of this point need to be classified into the bottleneck analysis and positioning of the application itself.

At present, basically all the things are inseparable from the database background. the bottleneck of the database is really unknown. The work of the database administrator and the daily work of the database administrator, it may be a task with a bottleneck, for example, querying V $ sys_event, V $ sysStatFor tables such as v $ syssql, compare the monitoring data under normal conditions and check whether there are any exceptions. I don't know much about other aspects.

Application bottleneck. This is the most important thing to pay attention to during the testing process. We need the testing staff and developers to work together and locate the issue. What I do here is mostly executable, for example, if there is a script to run, the developer will combine the jproFileR and other tools. Let's take a look at the heap traversal and check the thread analysis to determine where the problem is. This is basically the case. No actual operations have been performed.

Gradually refine the analysis. First, we can monitor some common performance metrics of CPU, memory, and disk, perform a comprehensive analysis, and then locate the problem based on the actual situation of the tested system, then determine more detailed monitoring metrics for analysis.

When you suspect that the memory is insufficient:

Method 1:

[Metrics]: Memory Available MBytes, Memory Pages/sec, page read/sec, Page Faults/sec

[Reference value ]:

If the Page Reads/Sec ratio persists to 5, the memory may be insufficient.

Page/sec recommends 00-20 (this value will remain high if the server does not have enough memory to handle its workload. If it is greater than 80, it indicates a problem ).

Method 2: analyze performance bottlenecks based on Physical Disk values

[Metrics]: Memory Available MBytes, Pages read/sec, % Disk Time and Avg. Disk Queue Length

[Reference value]: % recommended Disk Time threshold of 90%

When the memory is insufficient, some processes will be transferred to the hard disk for operation, resulting in a sharp decline in performance, and a system with a lack of memory often shows a high CPU utilization, because it needs to constantly scan the memory, move the pages in the memory to the hard disk.

Suspected Memory leakage

[Metrics]: Memory Available MBytes, Process \ Private Bytes and Process \ Working Set, PhysicalDisk/% Disk Time

[Note ]:

In Windows resource monitoring, if the value of the Process \ Private Bytes counter and the Process \ Working Set counter continues to increase for a long time, and the value of the Memory \ Available bytes counter continues to decrease, memory leakage may occur. Memory leakage should be tested through a long period of time to study and analyze the test of application response when all memory is exhausted.

CPU Analysis

[Metrics ]:

System % Processor Time CPU, Processor % Processor Time CPU

Processor % user time and Processor % PrivilegEdTime

System \ Processor Queue Length

ContExT Switches/sec and % Privileged Time

[Reference value ]:

System \ % Total processor time does not last more than 90%. If the Server is dedicated to SQL Server, the acceptable maximum allowed time is 80-85%, and the valid range is 60% to 70%.

Processor % Processor Time less than 75%

System \ Processor Queue Length value, less than the total number of CPUs + 1