How Many Concurrent Requests Can Spring Boot Handle?

Spring Boot is a widely adopted Java framework for building web applications and RESTful services, and understanding its ability to handle concurrent requests is essential for ensuring high‑throughput and stable systems.

Request handling in Spring Boot

Spring Boot delegates HTTP handling to an embedded web server such as Tomcat, Jetty, or Undertow. The server assigns each incoming request to a thread from its thread pool; the pool size therefore determines the maximum number of requests that can be processed simultaneously.

Default Tomcat thread‑pool configuration

When no custom settings are provided, Spring Boot uses Tomcat with the following defaults:

max‑threads : 200

min‑spare‑threads : 10

accept‑count (request queue size) : 10,000

These values mean Tomcat creates a pool of 200 threads and can queue up to 10,000 additional requests; requests beyond the pool are held in the queue until a thread becomes free.

Adjusting the thread pool

Developers can increase concurrency by modifying the Tomcat settings in application.properties or application.yml. Example for application.properties:

server.tomcat.max-threads=500      # increase maximum threads
server.tomcat.min-spare-threads=20 # increase minimum idle threads
server.tomcat.accept-count=10000  # keep the queue size

Equivalent YAML configuration:

server:
  tomcat:
    max-threads: 500
    min-spare-threads: 20
    accept-count: 10000

Changing these parameters allows the application to handle more concurrent requests under high load.

Simulating concurrent requests with async controllers

To observe how Spring Boot behaves under concurrency, an async controller can be created using the @Async annotation. Example controller:

package com.example.demo.controller;

import org.springframework.scheduling.annotation.Async;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import java.util.concurrent.CompletableFuture;

@RestController
public class HelloController {
    @Async
    @GetMapping("/async")
    public CompletableFuture<String> asyncHello() throws InterruptedException {
        Thread.sleep(2000); // simulate a time‑consuming operation
        return CompletableFuture.completedFuture("Hello, Spring Boot!");
    }
}

The main application class must enable async processing:

package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.scheduling.annotation.EnableAsync;

@SpringBootApplication
@EnableAsync
public class DemoApplication {
    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }
}

When the /async endpoint is hit, Spring Boot uses a separate thread to handle the request, introducing a 2‑second delay. Scaling the number of simultaneous calls reveals how the configured thread pool limits affect throughput.

Measuring real‑world capacity

To determine the actual maximum request count, developers typically employ load‑testing tools such as Apache JMeter or Gatling, which can generate large numbers of concurrent requests and help identify bottlenecks.

Key factors influencing concurrency

Thread‑pool size : Adjust max-threads and min-spare-threads to raise the number of concurrent requests the server can process.

Hardware resources : CPU cores, memory, and other server resources limit how many threads can run effectively; insufficient resources cause timeouts or failures.

Operating‑system limits : File‑descriptor limits and OS‑level thread caps also constrain concurrency.

By tuning the thread‑pool configuration, ensuring adequate hardware, and respecting OS limits, Spring Boot applications can be optimized for high‑concurrency scenarios.