Chapter 3: Developing a Performance Testing Engine

Chapter 3: Developing a Performance Testing Engine

After learning the basics of Java multithreading, we are ready to create a powerful engine that will expand our performance‑testing capabilities.

In this chapter we will develop a Java‑based performance testing engine by breaking down typical testing requirements, designing solutions, and implementing them step by step.

During the process we will apply the knowledge and skills acquired in the previous chapters, strengthening our proficiency for more challenging projects.

3.1 Performance Testing Model

For newcomers, performance testing models can be unfamiliar because many tools hide the underlying mechanisms, exposing only concepts such as thread count, user count, and concurrency. To ease the transition from tool‑based testing to pure Java testing, we start with a small story.

3.1.1 Supermarket Story

Imagine the "Xiao Ba" supermarket from Chapter 1 has expanded to eight checkout lanes, each staffed by one cashier.

Two design options are considered: a "queue" scheme where each lane has its own waiting area, and a "throttling" scheme where customers first enter a common area before choosing a lane.

During peak hours each checkout can process a customer in 2 minutes, i.e., 4 customers per minute. When demand exceeds this, the two designs behave differently.

Queue scheme: Customers join the shortest lane; long queues form if demand is high.

Throttling scheme: Only a fixed number of customers (e.g., 4 per minute) are allowed into the common area; excess customers wait outside.

If a cashier is absent (e.g., due to rain), the queue scheme simply closes that lane and redistributes customers, while the throttling scheme continues admitting customers at the preset rate, eventually causing severe congestion.

Introducing two elderly customers who each need 10 minutes to checkout further highlights the differences: the queue scheme elongates the line behind them, whereas the throttling scheme blocks two lanes for a long time, causing accumulation of waiting customers.

Additional scenarios (e.g., two friends with limited cash) illustrate how the queue scheme can respect ordering while the throttling scheme may break required sequences, potentially leading to deadlock‑like situations analogous to Java multithreading.

In this analogy, the checkout counters represent the service under test, customers are client requests, and the time from entering the checkout area to leaving the supermarket corresponds to response latency.

When customers queue before the checkout, the service processing time per request remains unchanged; when they queue inside the checkout area, waiting time adds to the overall response time.

The deadlock scenario described mirrors typical Java multithreading pitfalls.

The two designs map to the thread model and the TPS (Task Per Second) model respectively. TPS is akin to QPS/RPS and denotes the number of tasks executed per unit time.

3.1.2 Thread Model and TPS Model

Thread Model uses threads as the smallest management unit; each thread repeatedly executes a task. By adjusting the number of running threads, different load levels can be simulated.

Pseudo‑code example:

public static void main(String[] args) {
    for (int i = 0; i < N; i++) {
        new Thread() {
            @Override
            public void run() {
                for (int j = 0; j < M; j++) {
                    executeTask();
                }
            }
        }.start();
    }
}

TPS Model uses tasks as the smallest unit; an executor fires tasks at a configured rate. By changing the execution rate, different pressure levels are simulated.

Pseudo‑code example:

public static void main(String[] args) {
    while (true) {
        Thread.sleep(1000);
        for (int i = 0; i < N; i++) {
            executor.executeTask(task);
        }
    }
}

Both models have advantages; the thread model is easier to implement and manage, so the remainder of this chapter focuses on it. The TPS model will be introduced later as a more advanced version.

3.1.3 Outlook for the Performance Testing Engine

Beyond the basic unit of execution, performance testing can involve static and dynamic models. Static models fix pressure strategies before execution (e.g., ramp‑up, max load), while dynamic models adjust pressure on‑the‑fly based on service metrics.

Designing an engine that supports dynamic adjustment, stronger multithread management, and eventually distributed load generation represents the next milestones after completing the hands‑on sections of this book.

Book title: "Performance Testing Starting from Java".

If you find this material helpful, consider supporting the author; a modest contribution grants early access to unpublished chapters and video tutorials.

FunTester Original Highlights [Series] Performance Testing from Java Chaos Engineering, Fault Testing, Web Frontend Server‑Side Functional Testing Performance Testing Topics Java, Groovy, Go White‑Box, Tools, Crawlers, UI Automation Theory, Insights, Videos