Shulou(Shulou.com)06/03 Report--

What is a performance problem?

The first performance problem is shown.

When used on a small scale, the performance is very good, when used on a large scale, the performance becomes very poor, and the business response time becomes slower and slower with the business pressure.

Cause: bottleneck in the use of resources in the code, and subsequent requests are queued on resources (cpu, memory, locks, thread pool)

Example: with the increase of business, the number of rows of the table increases rapidly, and the query becomes slower and slower.

Most of the problems solved by performance testing are of this type

The second type of performance problem

Under certain pressure, the performance of the application suddenly deteriorates or cannot be used

Reason: the application suddenly enters an exception logic, takes up a lot of resources, and cannot exit from the abnormal state

Example: synchronous socket connection is used in the early version of fetion backend. When a single point of network is abnormal, the services of the whole network are not available.

Performance testing is difficult to solve this type of performance problem. It is difficult to locate what the exception logic is.

The third type of performance problem

When the pressure is greater than a certain threshold, there will always be a small number of business errors

Reason: business logic is not carefully considered, resulting in a small number of processes that do not occur as expected

Example: take a value as the uniquekey value, the lock protection is not enough, the value is not unique.

Performance testing can solve these problems very well.

Detailed analysis of some basic concepts

Response time

Response time is an index to examine the performance of the software under test in performance testing.

Response time includes the sum of time from the time the client request is sent to the time when the reponse reply is returned, and may include:

Network transmission

Wait time for executable queues on cpu

Cpu calculation

The time that the thread executes the sleep statement

Waiting time for locks and latches

Disk io wait time, etc.

Throughput tps

Throughput tps is another indicator of performance

Tps is a specific and commonly used indicator of the amount of business completed per unit time, the number of businesses completed per second.

The common misunderstanding is that response time must affect tps, which may not be true.

Concurrence

Concurrency refers to the number of requests processed at the same time, and simultaneous processing can have two meanings

Requests all on the thread stack at the same time

Refers to a request that is being processed on cpu

This refers to the latter.

Then the maximum tps = Concurrency*1000 / processing time of the request on the cpu (ms)

Thinking time

Think Time think time Think time is a concept that appears in the test code. Sleep time is added in order to simulate the time user's thinking time in the test code.

The first function is to control the business execution speed of the test code and execute the expected scenario perfectly.

Simulate the thinking time executed by the actual user

Stateful services are important

Stateless services are not important

Test pressure business load

What is the test pressure? Or what the customer has done to cause the server to be stressed.

For stateless servers, the pressure on the client comes from the number of requests per second from the client

For stateful servers, the pressure on the client is the client's retained information and rps on the server.

The database is a stateful server

Stateful servers are more likely to have performance problems

Performance testing process

A perfect testing process

Perfect performance testing is the process in which the software actually runs on the current network.

It can never be completely simulated in the laboratory.

The performance test could not find all the problems

Performance testing scheme

It defines what kind of methods and strategies are used to simulate the real situation in all aspects that affect the performance of the software, so as to achieve the purpose of true simulation as much as possible.

It is very important to determine the success or failure of the test.

Basic data: the sum of the data already in the test environment before testing

Principles on basic data

You must investigate or predict how many rows there should be in each table in the database table.

And the value of the data should be as rich as the actual situation.

The data length is the same as the actual situation.

The basic data determines the logic of the cpu, memory, io usage or other multiple resources of the database server.

Test data: data selected from basic data to participate in performance testing

Principle of choice

Randomly select data and select sufficient quantity within a reasonable range of application.

The way you pick data usually affects the memory and io of the database, cpu and memory of stateful services, threads, locks, and so on.

Business model

What services have been completed by the test? Rate of completion?

Principles for building business models

The best is the statistics of actual user behavior, if there is no statistics of user behavior with the help of similar software, no more, according to the estimates of experienced people.

Sort all possible user services according to the frequency of use, and the higher the frequency, the more should be included in the test scenario.

Check the extent to which the business consumes computing resources. It is expected that the greater the consumption, the more it should be included in the test scenario.

Principles for building business models

Complex scenarios in which multiple businesses come together: put the tps of all businesses in the cycle together. In general, all businesses will have consistent behavior, that is, the tps changes are consistent, and the tps in the peak phase is taken as the test pass standard.

How there are obvious inconsistencies needs to be tested in 2 or more typical scenarios.

Test scenario

How much testing pressure (how many online users or what is the rps)

Results of estimated and actual predictions

How long will it take to test?

A few hours of statelessness

A few days in a state

Principles of hardware resource selection

Each role in large-scale distributed software requires a load balancing design to scale smoothly. Then the test environment only needs to obtain such a small collection of environments.

It is best for a single hardware device to use the machine after it is online, because there are great differences between different devices, and it is impossible to analyze the differences between hardware from cpu, memory, tpcc and other indicators.

Testing with equipment with great differences can only explain the problem qualitatively, not quantitatively.

How to write test code

Be able to complete business functions like actual customers. This is the most basic ability and the basis of performance testing.

Strictly check the correctness of the results of each interaction with the server to ensure the correctness of the function execution. The goal of performance testing is not only to provide the working pressure of the test, but also to ensure the correctness of the test function.

Provide error logging function, which is a very good means for preliminary analysis of performance problems, or for testing code or functional problems of the software under test. Optional

The test code should be designed consciously to ensure the stability of the amount of data in the database, optional.

Improve the configurability of test code to ensure that test scenarios can be quickly established in a variety of different test scenarios.

Competency requirements of test executor

Testers need to configure test code and use test tools to establish test scenarios in accordance with the requirements of the test scheme, which is a must.

It is necessary to select reasonable test data according to the scheme.

The tester must fully understand every detail of the test code. If any error is found in the test, if the error is a problem with the test code or scenario settings, the tester has the ability to solve it.

It is required to determine whether there are any performance problems in the analysis of the test results.

For the problems of the service side, it is optional to provide the context at that time for developers and optimizers to analyze.

It is optional to solve the simple problems caused by configuration errors of the software under test.

Basic steps of software optimization

What are the performance issues? Bottleneck of cpu, bottleneck of memory, bottleneck of disk io, bottleneck of network io, bottleneck of synchronization between threads, etc.

What should it be like after the software is optimized? Features

Basically, Tps is positively related to cpu utilization.

Response time 1-50 ms, tps tens of millions

Refer to the resources such as the test equipment cpu

Complexity of the business completion process

If there is a performance bottleneck

First, check out other bottlenecks to ensure that tps and cpu are positively correlated.

Check to see if there is any abuse of cpu

"all problems with high cpu are caused by unnecessary cycles"-personal experience

Queries for tables without indexes

The application has no cache locally and is repeatedly fetched from the database or other applications.

Too many threads, resulting in too much context switching.

Limitations of performance testing

When is the performance test inaccurate?

The limitation of performance testing leads to uncertainty.

Scenarios and businesses that are not tested

Software exception flow

The hardware and network environment are different.

For example, the client is particularly mobile and the network speed of the client is slow.

Uncertainty caused by changes in user behavior

Uncertainty caused by the growth of user data

An example of performance optimization

Introduction to the problems of the system under test: a system using dot net remoting, which has been used online for more than a year, suddenly has a serious outofmemory problem.

Very heavy load: calls to remoting during busy hours are about 0.35h / s.

Cpu usage is low: only 1% on average

Memory only rises and does not fall, reaching its maximum value in a few days, resulting in outofmemory. As shown below:

From the application point of view, only 20 clients are used online every day. How did hundreds of tcp connections come from?

Reason: the network is abnormal and the connection has been interrupted, but server is not aware of it.

The application is deployed on win2000, and win2000 is not aware of connection anomalies

Solution: upgrade to win2003, add tcp connection detection to the registry, check every 90 seconds

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.