Ending Remarks Do real performance projects #

Hello, I’m Gao Lou.

Here, I have finally finished writing and updating the second course. To give you a rough idea, the main text of this course is over 180,000 words, and the environment setup section has over 90,000 words. Altogether, there are about 280,000 words, all written manually, with no additions.

Compared to the previous course, “Practical Performance Testing in 30 Lessons,” I felt that this course was very challenging to write, because all the case studies are not fabricated but rather based on real systems. I analyzed various problems encountered in facing an unknown system one by one.

If you have taken the previous course, you will notice that my focus was on analyzing individual components, aiming to explain the analysis logic of each component as clearly as possible. However, there is not much connection between the chapters, which is not sufficient to support us in doing good performance projects.

In an actual project, when we analyze performance bottlenecks, analyzing individual components alone usually does not provide a chain of evidence unless we happen to analyze the problematic components. Therefore, from a logical standpoint, only by conducting correlated analysis can we develop more effective strategies. That’s why, in this course, I will use case studies to show you my overall analysis process.

Of course, there is also a more important reason, which is to help you cultivate your “internal strength.”

To Conduct Performance Analysis, You Must Have “Internal Skills” #

I have always stressed that performance should be an engineering-level activity. However, nowadays many companies have turned it into a task during the testing phase. As a result, even after completing the testing tasks, there is still uncertainty about whether the system can run properly. Once the system is online, operations and maintenance are overwhelmed with dealing with various continuous issues.

What’s even worse is that the “testing” industry pays more attention to tools than performance goals, and even overlooks the importance of self-analysis abilities. Therefore, many people, even after conducting tests, are unsure if they have met their goals. This is like having the Heaven Sword and Dragon Saber, but having no internal skills to fully unleash their power. However, if you possess the Nine Yang Divine Skill, it would be different; you won’t be overly concerned about what kind of weapon to use.

Therefore, in my RESAR performance engineering philosophy, I want to tell you that to conduct performance analysis, you must have “internal skills”.

So what kind of internal skills do we need? Have you seen the following performance analysis and optimization technology map? The technologies depicted in this map are the internal skills we need to cultivate.

You might wonder: there is so much content here, how can one person possibly achieve all of this?

Before having this thought, have you tried and made an effort? In fact, you can simply select one module from this map and then choose one technology component to thoroughly understand it; most similar technology components will be easier to grasp as well. Our focus is on mastering the performance analysis logic behind them, rather than learning how to use all the tools.

For example, the two most important technical logics in our course are the performance analysis decision tree and the performance bottleneck evidence chain. These two technical logics teach you how to think and analyze performance issues. If you want to learn tool operations, you can easily practice by following the tool manuals.

In fact, when it comes to basic knowledge and technical details, whether you read books or take courses, I believe there is only one way to progress the fastest, and that is “hands-on practice”.

But the current situation is that most people only practice hands-on during actual work and only look at materials when not working. This is why many people seem to understand the material, but are unable to apply it when they try.

It’s like some people complain about gaining weight while indulging in eating and drinking without exercising. These people are completely driven by inertia and will only seek help when they face real danger. The power of human inertia is really immeasurable and difficult to stop.

But you must understand that learning and thinking are unavoidable processes for everyone, and internal skills cannot be developed in just a few days of intense training. As long as we start and continuously improve ourselves, even if we only learn one piece of knowledge in a day, after a certain period of time, we will overcome our inertia and enjoy the pleasure that progress brings. In the long run, those complex basic knowledge and technical details will become ingrained in our minds.

Once you have acquired this knowledge reserve, the next question you will face is: How do you integrate them?

This is where “thinking” comes in, which is the methodology that emerges from the application of this knowledge. This is very important because if you don’t master this stage, you will remain limited to the level of tools.

And the methodology I am talking about is actually the “RESAR performance engineering” that I want to teach you in this course:

However, you must remember that a methodology is only valuable when it is implemented, which is why in this course, I have tried to include every detail and provide you with a reference.

Deriving the Value of Performance Engineering from Performance Objectives #

While you cultivate your skills, I also hope you can improve your understanding of performance and truly grasp the value of performance projects.

Because when you look around, the performance market is really at a standstill, just like the large mud pit in the center of East Second Avenue in the novel “Hulan River Chronicles”. Even though most people know the dangers of the mud pit, aside from the individuals who are deeply stuck in it and the enthusiastic people helping them, others either applaud or mock, choosing to walk by the roadside tree roots every day without considering filling in the pit.

This phenomenon is very common. In a company, few people calculate how much profit loss is caused by performance issues, and no one calculates the cost incurred due to poor system performance. Some companies even use tens of thousands of CPU resources (with a utilization rate of less than 5% per day) to maintain a sense of security; other companies become furious when faced with online performance issues but fail to reflect on their actions after extinguishing the fire… all of these phenomena stem from a lack of understanding of performance.

Some people may argue that investing more in manpower and time costs for performance does not guarantee results. Yes! That’s the key! What exactly is the result? Isn’t it the guarantee for production? The real value of performance lies in providing assurance for business capacity.

However, the reality is that most performance personnel cannot achieve this, which is why the value of performance is constantly underestimated. As a result, performance projects can only become perfunctory rituals, where systems go live only to face imminent failure.

When I was reviewing a performance standard before, I held several expert group discussions. During these sessions, the debate on whether performance projects need to be optimized continued without resolution. Some believed that with short test cycles, there was no need for extensive optimization. Some felt that expecting performance engineers to understand the architecture was pushing it. Others thought that performance testing was just a short-term task during the testing phase and did not need to be overly critical…

In such meetings, after silently listening to everyone’s remarks, I said, “I have just one question. If you can solve this question, you can go according to your own approach. My question is, can your approach clearly determine the maximum capacity of the system?” Suddenly, everyone fell silent, and the room became terrifyingly quiet.

This is the understanding that many people have about performance. In their minds, this conclusion is simply impossible to achieve because they have always viewed performance within the scope of their job responsibilities.

If we derive how performance should be done from the performance conclusion (objective), then it becomes evident that performance should not be limited by personal or fixed team technical capabilities. Instead, it should be approached from the standpoint of cost and profit loss.

It is for this reason that when I was drafting that performance standard, I did not hesitate to include sections on “optimization” and “year-on-year comparison of online performance data,” making performance a complete closed loop.

This course is also based on this complete closed-loop thinking and proposes the RESAR Performance Engineering methodology. In this methodology, I have thoroughly explained all the aspects that I can think of. If you feel that they are not clear enough or not complete enough, feel free to discuss with me anytime. I am open to debating within the limits of theory without taking any physical action.

Transformation requires a change in thinking #

After my last course was released, many people approached me to discuss how I challenged their understanding of performance and touched upon sensitive psychological boundaries. As a result, some were eager to debate the issue of performance methodology.

After patiently listening to their flawed arguments, I told them: If you can present a project to me that fully implements the methodology you described, without being questioned, and demonstrates the value of your methodology, then I will consider you to be correct. If you have not done so, please refrain from wasting my bandwidth.

To be honest, my purpose in summarizing and reflecting on each performance project is not to engage in pointless debates or seek meaningless vanity and satisfaction. What I hope for is that my methodology can be effectively implemented and demonstrate the value of performance projects. If your intention is simply to provoke controversy without practical application, you should study the strategies of Wang Yan in the Western Jin Dynasty, instead of working in an industry that requires practical knowledge.

The transition from performance “testing” to performance “engineering” is a necessary transformation in the thinking process of every performance professional. The technical and business value demonstrated in the implementation of performance engineering is the true test of its practicality. Without considering its value, it is ultimately futile.

In this course, the complete content I want to convey about performance engineering includes performance solutions, business models, scenarios, data, environments, as well as specific analysis logic, concurrent computing, and performance monitoring. Only through this can you truly work on a valuable performance project.

In conclusion, I hope that you, as a learner of this course, will carefully consider my philosophy. As for the extent to which it can be effective, it depends on your foundational knowledge. I also hope that through continuous practice, you can enrich your logical thinking and work on truly valuable performance projects, free from entanglement, blind adherence, compromise, or arrogance.

At the end of the course, I have prepared a course feedback questionnaire for you. I would appreciate it if you could take one minute to fill it out. I would like to hear your feedback on this course. By completing the questionnaire, you will have the chance to receive a minimalist baseball cap or a course access code worth 99 yuan. I look forward to hearing your thoughts.