How Many Requests Can a Default SpringBoot App Handle? Uncover Tomcat & Undertow Limits

Hello, I am SanYou.

This article examines the interview question: "How many requests can a SpringBoot project handle simultaneously?" It explains how to clarify requirements, build a minimal demo, and determine the answer through practical testing and source‑code analysis.

Demo

A simple SpringBoot 2.7.13 project is created with only two dependencies and an empty application.properties. The project contains a TestController with a getTest endpoint that logs the request and then sleeps for one hour, effectively holding the request thread.

@Slf4j
@RestController
public class TestController {
    @GetMapping("/getTest")
    public void getTest(int num) throws Exception {
        log.info("{} received request:num={}", Thread.currentThread().getName(), num);
        TimeUnit.HOURS.sleep(1);
    }
}

A test class repeatedly creates new threads that call the endpoint:

public class MainTest {
    public static void main(String[] args) {
        for (int i = 0; i < 1000; i++) {
            int finalI = i;
            new Thread(() -> {
                HttpUtil.get("127.0.0.1:8080/getTest?num=" + finalI);
            }).start();
        }
        Thread.yield(); // block main thread
    }
}

Running the demo and counting log lines shows that 200 requests are processed concurrently.

Answer

The answer to the original interview question is 200 concurrent requests for a default SpringBoot project, because SpringBoot uses Tomcat as its embedded web container.

How It Comes

Tomcat, not SpringBoot, manages the request threads. By inspecting a thread dump, the log reveals threads belonging to org.apache.Tomcat.util.threads.ThreadPoolExecutor. Tomcat’s default configuration is:

corePoolSize = 10

maximumPoolSize = 200

queue capacity = Integer.MAX_VALUE

Unlike the standard JDK thread pool (core → queue → max), Tomcat first uses the core threads, then directly expands to the maximum threads before the queue is considered. Therefore, with default settings, up to 200 requests can be handled simultaneously.

The relevant source code shows the logic in ThreadPoolExecutor#executeInternal and the custom TaskQueue#offer method, which decides whether to enqueue a task or create a non‑core thread based on the current pool size.

Configuration Details

Additional Tomcat parameters affect concurrency: server.tomcat.max-connections defaults to 8192; setting it to 10 limits concurrent connections to 10. server.tomcat.accept-count defaults to 100 and controls the backlog of pending connections.

Undertow Comparison

Switching the embedded container to Undertow (by changing Maven dependencies) changes the concurrency characteristics. In the author's environment (6 CPU cores), Undertow’s thread pool defaults to 48 worker threads (coreSize = maxSize = 48) and an unbounded queue.

Undertow derives the worker thread count from cpuCount * 8. The relevant source shows the builder setting coreSize and maxSize to this value.

Further Observations

Adding @Async introduces another thread pool with a default core size of 8, reducing the number of concurrent requests the application can handle to 8.

The article concludes with interview advice: always clarify ambiguous requirements, understand the underlying container defaults, and be prepared to discuss differences between Tomcat, Jetty, Netty, and Undertow.