API Load Testing with Postman, ApacheBench, JMeter, and Java Concurrency

Hello everyone, I am a senior architect.

1. Postman

Postman is an HTTP request simulation tool. The article first shows the most basic usage of Postman.

It creates a Spring Boot project with the following test code:

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequestMapping("test")
public class TestConrtoller {

    @GetMapping("demo")
    public String testDemo() {
        return "result~";
    }
}

For convenience, the common address http://127.0.0.1:8080 can be set as an environment variable.

The article then walks through the steps to set a global variable in Postman: click the settings icon, choose "Global", and enter the address.

After the basic usage is understood, the article shows how to simulate concurrent testing with Postman.

2. Apache Bench (AB)

ApacheBench is a command‑line web stress testing tool that comes with the Apache server. It can generate many concurrent threads to simulate multiple users accessing a URL, providing basic performance metrics without a graphical interface.

The article explains how to install Apache on Windows (download the Windows version from the Apache website) and configure it by editing httpd.conf to set the server root, listening port, and document root.

After installation, the service is started with:

httpd.exe -k install

and later with:

httpd.exe -k start

Testing is performed using the -n (number of requests) and -c (concurrency) options.

3. JMeter

JMeter is a graphical performance testing tool. The article provides the download link and notes that Java 8+ is required.

After extracting JMeter, you start it via jmeter.bat , create a Thread Group, add an HTTP Request, and attach listeners such as a Graph Result and View Results Tree.

Before running the test, open the Log Viewer, then execute the test and view the results.

4. Code‑based Concurrency Simulation

The article introduces CountDownLatch , a synchronization aid that allows one or more threads to wait until a set of operations completes. It explains its constructor and three main methods: await() , await(long timeout, TimeUnit unit) , and countDown() .

It also covers Semaphore , which limits the number of concurrent accesses to a resource, with acquire() and release() methods.

Using these classes, the article provides a Java example that simulates 5,000 total requests with 200 concurrent threads:

import lombok.extern.slf4j.Slf4j;
import java.util.concurrent.*;

@Slf4j
public class CuncurrencyTest {

    // total number of requests
    public static int clientTotal = 5000;
    // number of concurrent threads
    public static int threadTotal = 200;
    public static int count = 0;

    public static void main(String[] args) throws InterruptedException {
        ExecutorService executorService = Executors.newCachedThreadPool();
        final Semaphore semaphore = new Semaphore(threadTotal);
        final CountDownLatch countDownLatch = new CountDownLatch(clientTotal);

        for (int i = 0; i < clientTotal; i++) {
            executorService.execute(() -> {
                try {
                    semaphore.acquire();
                    add();
                    semaphore.release();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                    log.error("exception", e);
                }
                countDownLatch.countDown();
            });
        }
        countDownLatch.await();
        executorService.shutdown();
        log.info("count:{}", count);
    }

    private static void add() {
        count++;
    }
}

The article notes that the count variable is not thread‑safe, leading to incorrect results, and emphasizes that CountDownLatch and Semaphore have broader uses beyond testing.

Finally, the article provides a list of interview questions (BAT) and invites readers to join a senior architect community for further discussion.