“This is the 20th day of my participation in the August Gwen Challenge.

One, foreword

Performance scenarios are a critical part of performance testing.

However, among the students and companies I spoke to, I found that many people did not pay much attention to the details of the performance scenario.

Two, single service pressure measurement strategy

There’s only one place I’m going to write today, and that’s the pressure measurement strategy. Pressure measurement strategies are varied and Settings are varied. For example, the following (using JMeter for example, other tools only have different configuration methods).

1. Strategy 1

  • There are 100 threads (called vusers in loadRunner) in this policy, adding 10 users every 30 seconds at 6-second increments. In other words, the 10 users in the 30 seconds were added by 2 users at a time;

[Fixed] 60 seconds after 10 users are added.

  • Threads are stopped at five users per second until they are stopped.

  • When the scene starts, there are no threads to start, meaning that there are no threads to start for the first 6 seconds, and two threads to start after 6 seconds.

2. Strategy 2

In this strategy, we can see the following:

  • 100 threads started at the same time;

  • Lasts 600 seconds;

  • And stop at the same time;

3. Strategy three

The strategy is:

  • Start 10 threads;

  • Then 10 threads are started every 10 seconds until 100 threads are started.

  • Lasts 600 seconds;

  • Then stop 10 threads every 10 seconds.

4, review

Take these three strategies, for example. Because it’s typical. What pressure measurement strategy should be used when? That’s the key question.

The first thing to define is the goal of the test. If the maximum capacity of the system is not known, the first pressure measurement strategy is obviously the most reasonable, because the relationship between response time and TPS can be seen during the process of increasing pressure.

So what’s the difference between the third pressure test strategy and the first one? The third strategy is listed because the first strategy is used by very few people. And the third kind is relatively more common. The goal is the same as the first one. Just this time to grasp the extent of the increment thread.

My advice is to use the first strategy when you don’t know the maximum TPS of your system. Because using the third one, you may need to try several times.

What about the second pressure measurement strategy? I’ve met a lot of people who use the second strategy. And most of them don’t know what the consequences of this strategy are.

Usually, this pressure testing strategy is only used in seconds, auctions and other scenarios. Some say that such a strategy should be implemented with collection points. Note that it is best not to use assembly points unless you know exactly how much pressure to apply to such a scenario after analyzing it.

There has to be a calculation involved.

Some people prefer to use the second pressure measurement strategy to achieve 100, 200, 300, 400, such as single scene increments. In fact, in the actual application scenario, this is a brief scene. Therefore, this approach is only at the moment of peak testing, which is not necessary in the actual performance scenario. It should be said that it oversimplifies the original application scenario.

3. Pressure measurement strategy in mixed scenarios

The pressure measurement strategy written above is for a single business.

Every time I do a project, I talk about benchmarking.

Earlier I saw someone define benchmarking as the basic validation of a script. Conceptually, this description is completely wrong. This question can be explained later.

For scenarios where multiple business scripts are mixed, the setup of each business script becomes a matter of necessity.

Therefore, what is needed before this is to analyze the characteristics of a single business until it can be set up in accordance with the real business scenario. This is critical. This is critical. If not, the whole process of performance test analysis and optimization is just to check the system for code problems, environment problems, configuration problems, data problems, architectural problems, etc.

Some say this is enough.

But are performance projects implemented just to find problems? Even if problems are identified, can the system hold up to real business scenarios? This is a question most people who do performance testing dare not answer.

Therefore, the important point of scenario design is to reproduce real business scenarios, and then analyze whether the system capacity meets business requirements.

Mixed scenes have different Settings in different tools.

1, LoadRunner

For LoadRunner, its setting of the scene is global in terms of design ideas. There is a feeling that all the business is controlled by me, which is a very overbearing global setting idea, and each business script can play its own space.

I like the idea of having a clear sense of control over the scene.

It just lacks flexibility.

Fortunately, LoadRunner has groups to make up for this lack of flexibility.

2, Jmeter

For Jmeter, the Settings are very loose, and the thread groups are individually set to play with as they please.

Therefore, for mixed scene setting, tools like Jmeter are more personal requirements.

As shown in the figure above, each thread group can have different initiation, persistence, and stop strategies.

No matter how the tool is set up, the most important thing is how to reproduce the real world, and the tool can’t tell you that. There is a lot of room for further development in both cloud and stand-alone performance testing tools.

It is in these flexible areas that performance testing has a big human role to play.

I’ve seen some self-developed tools give a simple script that can make billions of requests and call it a scene. That’s a very one-sided scenario, or the goal is not to replicate a real business scenario.

A complex scenario of a business

Some of the aspects of the pressure test strategy were mentioned earlier.

Now let’s look at the complex scenario setup for a business.

Yes, you read that right. It’s a complex set of scenarios for the same business.

We’ll talk about complex scenarios with multiple services later

After analyzing the business, you can set it up differently if the business has different peak hours.

Like this:The number of requests per hour varies.

This pressure measurement strategy should be developed for the performance execution scenario of the business.The configuration may be different in the same tool.

This can be done in one thread group, or it can be done in one thread group per hour of traffic.

So that the scene is similar to the actual scene.

One might think it would be ok to just design the scene for the hour of peak.

More than that.

Because there are still times for stress replenishment, things like batch processing will be added.

In addition, the open and close of resources can also be the point where problems occur.

Five, the summary

The real work is in the control of the details.

Performance is an art.