For most people, before doing performance testing, the most important thing is to figure out the performance testing requirements, and today it will be popularized with you. 
Generally speaking, the demand is probably like this:
1. Do a performance test for our system / product; (This kind of demand is generally too fictitious, and if it is not refined, it is basically not operable.)
2. Measure our maximum number of people online; (This kind of demand is basically capacity, let's take a look at the maximum capacity of the project / product.)
3. There is a problem online, but we can't find the cause of the problem. We hope to reproduce the problem under pressure to confirm some conjectures; (This requirement is to reproduce the online problem, requiring the script to simulate as accurately as possible. Real business.) 
As for how to do demand analysis, there should be an analysis before, so I wo n’t repeat it here. In many cases, it is often very difficult for test students to understand the purpose and requirements of performance testing. In addition to experience, we also need to have some common topics with development students to understand what development students think and what The problem needs attention. However, this requires us to have a certain understanding of the development technology, otherwise it is easy to produce information asymmetry between the development, and then develop the development, we measure ourselves, there is no synergy, the final result should be difficult to make Some people are satisfied.
In fact, in addition to demand, environmental factors are also very important.
The environment in which the performance test is measured is actually very knowledgeable.
In general, we recommend testing in an independent performance test environment that is almost identical to the online environment. why? To a large extent, it is the relationship of architecture. Different architectures have a huge impact on test results. In most cases, the difference between our test environment and the formal environment is quite obvious. The test environment may be a single machine, and the production environment may be a cluster. The problems we pressed on the single machine may not appear on the cluster. In addition, the problems that appear on the cluster may be difficult to reproduce on the single machine.
The easiest way to save trouble is to stress test in a formal environment, but this should pay attention to the problem of dirty data and error recovery. We hope that the pressure test in the formal environment will not affect the use of real users, will not modify the data of real users, and the system can be quickly restored after pressing out the problem. 
Of course, in most cases, it is dangerous to do stress testing in a formal environment. We generally recommend doing performance testing in an environment that is almost consistent with the production environment. So what does this almost mean?
1. The structure is basically the same, but it can be reduced. For example, there are 10 load balancing machines after the online reverse proxy. We may use 2 machines.
2. The amount of data is basically the same. There are 1 million pieces of data online, so we also use about 1 million pieces of data when we stress test.
3. Data desensitization. Don't expose users' sensitive information.
4. The network conditions are consistent. The bandwidth on the line is 1G, so the same bandwidth is used for the pressure test.
So after we have defined an independent performance testing environment, who will build and maintain this environment?
I suggest that test classmates build and maintain it themselves. Then the question is coming, if we build a test environment, in addition to some basic operation and maintenance operations (install software, modify configuration), what knowledge do we need?
We need to understand the architecture of the system.
During the interview, the interviewer likes to let the candidate simply draw a diagram of the architecture of the system he is testing. In addition, when you are technically upgrading in a company, no matter which technology channel, you will ask the architecture of your product. important. 
Building a test environment allows us to better learn the system architecture. Many newcomers will give him a few days to build a new development or test environment after they come. Sometimes it is a production-like environment. When setting up the environment, for example, we need to install redis, then we can ask the development classmates, redis What is it used for, what business scenario is it used for or what business problem is it used to solve. Over time, our ability to understand the architecture will definitely improve.
In addition, in many cases, the evolution of the architecture is to solve some known problems, or to be able to serve more users. The discussion and technical selection of this architecture replacement also contain the needs of performance testing. Go to the back door. Belden, many things will come handy.
Finally, the foundation is very important. If the foundation is good, some concepts may be smoother to understand. For example, the way of link layer forwarding for load balancing, if you do not understand the link layer, then the concept will be more difficult to understand.
All in all, before you do performance testing, you may need
1. Analyze the performance requirements clearly
2. Understand the system architecture
3. Build a test environment
4. Efforts to supplement basic knowledge
This is some of my insights, I hope to bring you some good suggestions, welcome to comment and publish your own suggestions in the comment area.