The server stability test methods are mainly as follows:

One. Stress test:

Knowing the number of users in the peak period of the system, verify whether the transaction response time of each transaction can meet the customer's requirements under the maximum concurrent number (converted by the number of people in the peak period). Whether the performance indicators of the system are still within normal values under this pressure. Will the system cause adverse reactions (such as downtime, abnormal application suspension, etc.) due to such pressure?

Second, Ramp Up incremental design:

For example, there are 75 concurrent users and 1500 registered users in the system, and use 5%-7% as the reference value for concurrent users. Generally, pressurization design is carried out by loading 5 people every 15s. This value mainly refers to the performance of the test press. It is recommended to run several times. The actual loading method is measured by transaction pass rate and error rate.

Three, Ramp Up incremental design goals:

Find the position of the bottleneck of the incrementally pressurized system performance and seize the opportunity of the performance inflection point. Generally, it is commonly used to refer to the comprehensive judgment of Hits click rate and throughput, CPU, and memory usage. Simulate the number of users during peak periods, such as logging in in the morning, logging out after get off work, and messaging system when salary is sent.

Another limit simulation method can be regarded as a system limit operation indicator that simultaneously clicks transaction operations under peak pressure conditions. The pressure method remains the same. Set the same rendezvous name in each script transaction point (such as: lr_rendzvous("same");). In the scenario design, use the transaction point rendezvous strategy. Based on the percentage of the rendezvous point reached at the same time, release all running Vusers at the same time.

Four. Stability test:

Known the number of users of the system during peak periods, the operating frequency of each transaction, etc. Design a comprehensive test scenario, and run each scenario together according to a certain proportion of the number of people during the test, simulating the use of users for several years. And monitor whether the performance indicators of the system can maintain normal values under this pressure during the test. Whether the transaction response time will fluctuate or increase with the growth of the test time. Whether the system will have abnormal conditions such as downtime, application suspension, etc. during the test period.

According to the above test, the position of the performance inflection point under each transaction condition is used to determine the number of concurrent users in the stability test. According to the actual test server (pressurizer, application server, data server three-party performance), estimate the final number of concurrent users.

You can also test the server in the following ways to verify whether the server has an automatic processing mechanism in various special situations:

1 Fault tolerance test

By simulating some abnormal situations (such as sudden power failure of the server, intermittent network intermittent, insufficient hard disk space of the server, etc.), verify whether the system can have an automatic processing mechanism to ensure normal operation of the system or measures to resume operation when these situations occur . If there is HA (Automatic Disaster Tolerance System), additional tests can be conducted specifically for these automatic protection systems to verify whether they can effectively trigger protection measures.

2 Problem exclusion test

Based on the original case or empirical judgment, verify the modules that have had problems or suspected hidden dangers in the system to verify whether these modules will have the same performance problems. Such as: the memory leakage problem of the upload accessory module, the optimization of the address book module, the impact of turning on Tivoli performance monitoring on the performance of the OA system, and so on.

Evaluation tests are related tests used to obtain key performance indicators of the system. It is mainly for no clear expected test results in advance, but to obtain performance indicators under specific stress scenarios (such as: transaction response time, maximum number of concurrent users, etc.) through testing.

Evaluate transaction response time: a test activity to obtain the response time of a transaction under a specific pressure. By simulating the stress values or expected stress values during peak periods of known customers, the response time of transactions under such stress is obtained.

Evaluate the maximum number of concurrent users of a transaction: a test activity to obtain the maximum number of concurrent users that a transaction can withstand in a specific system environment. By simulating the real environment or directly adopting the real environment, evaluate the maximum number of concurrent users that the firm can bear in this environment. The threshold of the judgment criterion needs to be defined in advance (such as response time, CPU usage, memory usage, 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, define the proportion of each transaction in the comprehensive scenario, and allocate the number of concurrent users of each transaction in a proportional manner. Simulate the real environment or directly adopt the real environment, and evaluate the maximum number of concurrent users that the system can withstand in this environment. The threshold of the judgment criterion is defined in advance (such as response time, CPU usage, memory usage, peak hit rate, peak throughput, etc.). The value standard is based on the barrel rule (the transaction with the smallest number of concurrent transactions is the number of concurrent transactions in the entire system).

Evaluate the impact of different database data volumes on performance: According to the test of different database data volumes, the test results are compared, and the data volume of each table in the database is analyzed and found to affect the transaction performance. It is possible to prejudge the hidden dangers that may exist after the system runs for a long time or when some module customers require a large amount of data.

Through the above test or actual operation of the user, the performance problem in the system or the suspected performance problem has been found, and the problem needs to be reproduced or defined through the response test scenario. If possible, you can directly identify the code or module causing the performance problem. This type of test is mainly used to test the script scenarios that have problems, and can add discovery and detection tools, such as turning on Tivoli performance monitoring, turning on HeapDump output, Linux resource monitoring commands, etc., and supplemented by manual testing during the running of the scenario.