Server stability is the most important. If the stability cannot meet the needs of business operation, it is useless for high performance.
Regular server manufacturers will test the operation stability of products under different temperatures and humidity. Redundancy functions, such as data redundancy, network card reputation, power redundancy, fan redundancy, etc., should be considered.
Some test methods are mainly divided into the following categories:
Stress test: Given the number of users in the peak period of the system, verify that the transaction response time of each transaction can meet customer requirements under the maximum number of concurrent transactions (converted by the number of users in the peak period). Whether the performance indicators of the system are still within the normal value under this pressure. Whether the system will cause adverse reactions (such as downtime, abnormal application suspension, etc.) due to such pressure.
Ramp Up incremental design: if the number of concurrent users is 75, the number of system registered users is 1500, and 5% - 7% is taken as the reference value of concurrent users. Generally, pressurization design is carried out by loading 5 people every 15s. This value mainly refers to testing the performance of the compressor, and it is recommended to run several times. The actual loading method is measured by transaction pass rate and error rate.
Ramp Up Incremental Design Objectives:
Find the performance bottleneck of the incrementally pressurized system, seize the opportunity of the performance inflection point, and generally refer to Hits click rate and throughput, CPU, and memory usage for comprehensive judgment. Simulate the number of users during peak hours, such as login in the morning, exit after work, and the messaging system when sending wages.
Another limit simulation method can be seen as the system limit operation indicator of clicking transaction operation at the same time under peak pressure. The pressurization method remains unchanged. Set the same assembly point name in each script transaction point (for example, lr_rendzvous ("same");) In the scenario design, the transaction point collection strategy is used. At the same time, release all Vusers running at the same time based on the percentage of meeting points reached at the same time.
Stability test: the number of users in the peak period of the system and the frequency of various transaction operations are known. Design a comprehensive test scenario. During the test, each scenario will be run together according to a certain number of people to simulate the use of users for several years. And monitor whether various performance indicators of the system can maintain normal values under such pressure during the test. Whether the transaction response time will fluctuate or increase with the test time. Whether the system will encounter abnormal conditions such as downtime and application suspension during the test period.
According to the location of the performance inflection point under each transaction condition in the above test, the number of concurrent users for stability test has been determined. The number of final concurrent users is still estimated based on the actual test server (the third-party performance of the pressurizer, application server, and data server).
Scenario design idea: from the design significance of the stability test scenario, it should be considered in various situations:
Taking the same scenario as an example, the following is a brief analysis of the scenario design idea with the example of uploading official document attachments:
1) Scenario 1: The concurrent users who have reached the performance inflection point in the stress test environment are designed to verify the performance indicators of the test server under extreme stress.
2) Scenario 2: According to the CPU, memory and other indicators in the stress test environment, select 50% of the maximum pressure that the server can withstand to determine the number of concurrent users.
Test method: 1) Ramp Up Load all Vusers similarly
2)Duration-Run Indefinitely
3) In Sechedule, check Initalize all Vusers before Run
Fault tolerance test: by simulating some abnormal conditions (such as sudden power failure of the server, intermittent network, insufficient space of the server hard disk, etc.), verify whether the system can have an automatic processing mechanism to ensure the normal operation of the system or restore operation measures when these conditions occur. If HA (automatic disaster recovery system) is available, additional tests can be conducted specifically for these automatic protection systems. Verify whether it can effectively trigger protective measures.
Problem elimination test: through the original case or experience judgment, verify and test the modules with problems or suspected hidden dangers in the system. Verify whether the same performance problem will occur for these modules. For example, the memory leakage problem of the upload attachment module, the optimization of the address module, and the impact of enabling Tivoli performance monitoring on the performance of the OA system.
The evaluation test is used to obtain the key performance index points of the system. It is mainly aimed at obtaining performance indicators under specific stress scenarios (such as transaction response time, maximum number of concurrent users, etc.) through testing without clear expected test results in advance.
Measuring transaction time: a test activity to obtain the response time of a transaction under a specific pressure. The response time of transactions under this pressure is obtained by simulating the pressure values or expected stress values of known customers during peak periods.
Maximum concurrent users of a transaction: a test activity to obtain the maximum concurrent users that a transaction can withstand under a specific system environment. By simulating the real environment or directly using the real environment, evaluate the maximum number of concurrent users that the transaction can withstand in this environment. The threshold value of the determination criteria needs to be defined in advance (such as response time, CPU utilization, memory utilization, peak hit rate, peak throughput, etc.).
Evaluate the maximum number of concurrent users of the system: a test activity to obtain the maximum number of concurrent users that the entire system can withstand. By pre analyzing the usage ratio and frequency of each main module of the project, the ratio of each transaction in the comprehensive scenario is defined, and the number of concurrent users of each transaction is allocated in a ratio manner.
Simulate the real environment or directly use the real environment to evaluate the maximum number of concurrent users that the system can withstand in this environment. The threshold values of the determination criteria are predefined (such as response time, CPU utilization, memory utilization, peak hit rate, peak throughput, etc.). The value standard is subject to the bucket rule (the transaction with the smallest concurrency is the concurrency of the whole system).
Evaluate the impact of different database data volumes on the performance: compare the test results for different database data volumes, and analyze the impact of the data volumes of various tables in the database on the transaction performance. It can pre judge the hidden dangers that may exist after the system has been running for a long time, or when some module customers require a large amount of data.
The problem location test has found performance problems in the system or suspected existing performance problems through the above tests or the user's actual operation. The problem needs to be reproduced or defined through the response test scenario. If possible, you can directly find the code or module that causes the performance problem.
This type of test mainly tests the script scenarios that have problems, and can add discovery and detection tools, such as enabling Tivoli performance monitoring, enabling HeapDump output, and Linux resource monitoring commands. In addition, manual testing is supplemented in the process of scenario operation.
