I. Introduction
Many students who do performance testing have asked me this question: Brother Yu (Carl_Yiran), what do you think is the point of performance testing?
My answer is simple: bottleneck analysis and problem location.
In the entire cycle of a performance project, whether it is script design, script writing or script execution, it is fairly simple.
The difficulty lies in how to locate the bottleneck, analyze the bottleneck, and solve the bottleneck.
If you don't know performance analysis, no matter how well the script is designed, no matter how perfect the script is written, if you can't analyze the problem, it is a waste of time.
So, in this lecture, let's learn: how to perform performance analysis, and learn the idea of performance analysis, in order to locate the problem, analyze the problem, and solve the problem.
In the performance project, the performance analysis ideas I summarized are divided into 5 modules, that is, 5 steps of performance analysis, as follows:
1. Determine the performance bottleneck;
2. Thread increment strategy;
3. Performance decay process;
4. Split response time;
5. Build an analysis decision tree;
Next, I will explain these five parts one by one.
2. Judging performance bottlenecks
During the entire performance testing phase, the most difficult thing for performance testing engineers is how to locate performance bottlenecks.
If the performance bottleneck cannot be located, then the support for the development students will be limited, which will undoubtedly increase the time to solve the problem and increase the workload of the development engineer.
At this time, you will say, isn't the responsibility of the development engineer to solve the performance bottleneck?
If so, the responsibility of the test engineer is not only to find performance bottlenecks, but also to locate performance bottlenecks, in other words, to assist development engineers to quickly locate and solve performance problems.
Why is it said that in the entire performance project, the most difficult thing is to analyze the performance bottleneck.
Here, I first put up a picture. In order to more vividly express the content to be described next, I processed the picture a little bit:
From this picture, we can intuitively know that this is a pressure measurement scenario with a stepwise increase.
However, according to this graph, can you judge where the inflection point is?
If you can't judge where the inflection point is, then I will post another ResponseTime (hereinafter referred to as RT) picture:
Similarly, in order to let you view the RT graph more intuitively, I also optimized the RT graph.
Combining the RT diagram and the TSP diagram, can we judge where the inflection point is?
If you think the position at 3.3s is an inflection point. I can't deny that what you said is completely wrong, but, I also don't agree with you, why?
Because, based on years of experience, the criterion for judgment is: with the continuous increase of TPS, find the clearly visible arc.
This is very important, you need to remember.
Let me give you an example: If you judge according to what you just said, just based on one inflection point, imagine,
If there is a sudden jitter in the network, according to the basis of your judgment just now (only based on one inflection point), is it inaccurate? .
Therefore, it must be to find the clearly visible arc.
We are coming back to talk about the above TPS diagram and RT diagram. Based on these two diagrams, what conclusions can you draw?
Can it be concluded that this system has a bottleneck, the bottleneck of the system is related to the pressure, and as the pressure increases, the increase is gradually decreasing.
At this point, I need you to think about a question: Is the bottleneck point related to the pressure?
Answer: Definitely not related to the size of the pressure.
Since it is not related to the size of the pressure, then what is the basis for it?
In fact, combined with the above figure, we can know:
① The problems that cause system bottlenecks are regular;
②TPS decreases periodically, and the maximum TPS is almost the same;
Therefore, even if the pressure is reduced, the maximum TPS water level is reduced at most. This situation only makes the problem appear a little later, but it will not disappear.
Finally, I would like to thank everyone who has read my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, you can take it away if you need it:
[The following is the most complete software test engineer learning knowledge architecture system diagram in 2023 that I compiled]
1. From entry to mastery of Python programming
2. Interface automation project actual combat
3. Actual Combat of Web Automation Project
4. Actual Combat of App Automation Project
5. Resume of first-tier manufacturers
6. Test and develop DevOps system
7. Commonly used automated testing tools
Eight, JMeter performance test
9. Summary (little surprise at the end)
life is long so add oil. Every effort will not be let down, as long as you persevere, there will be rewards in the end. Cherish your time and pursue your dreams. Don't forget the original intention, forge ahead. Your future is in your hands!
Life is short, time is precious, we cannot predict what will happen in the future, but we can grasp the present moment. Cherish every day and work hard to make yourself stronger and better. Firm belief, persistent pursuit, success will eventually belong to you!
Only by constantly challenging yourself can you constantly surpass yourself. Persist in pursuing your dreams and move forward bravely, and you will find that the process of struggle is so beautiful and worthwhile. Believe in yourself, you can do it!