6 Proven Spring Boot Performance Hacks to Slash Response Time

Hello, I'm your friend Architect Jun, a code‑writing architect.

Last Friday night, a colleague from an e‑commerce company called in panic: their promotion page was stuck, users were angry, and orders were failing. The culprit was a product‑query API that normally responded in tens of milliseconds but took over 5 seconds during peak traffic.

After diagnosing the issue, I shared a six‑step "combo punch" to dramatically improve Spring Boot performance.

1. Unclog the Tomcat thread pool

During traffic spikes, the default Tomcat thread pool (maxThreads=200, minSpareThreads=10) becomes a bottleneck. Increase the pool size according to server resources. Example configuration:

# application.properties - Tomcat thread pool tuning
server.tomcat.threads.max=800  # max workers, roughly CPU cores * 200
server.tomcat.threads.min-spare=100  # core workers always ready

After applying these settings, request queuing dropped from seconds to a few hundred milliseconds.

2. Offload slow tasks with @Async

Long‑running operations (e.g., sending emails, generating reports) block the main thread. Use Spring's @Async to run them in a separate thread pool, allowing the request thread to return immediately.

@Service
public class OrderService {

    @Async // run in async thread pool
    public void processSlowTask(Order order) {
        // simulate slow work, e.g., email, logging, risk check
        try {
            Thread.sleep(5000); // 5‑second slow task
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("【Backend completed】Order: " + order.getId() + " slow task finished!");
    }

    public String placeOrder(Order order) {
        // 1. quick DB operations...
        // 2. hand off slow work
        processSlowTask(order);
        return "Order submitted successfully! Please check notifications later."; // fast response
    }
}

Properly configure the async executor with @EnableAsync and a ThreadPoolTaskExecutor to avoid new bottlenecks.

3. Enable HTTP caching and compression

Static resources (JS, CSS, images) were being re‑downloaded on every refresh, adding unnecessary load. Configure cache‑control headers and enable gzip compression:

# application.properties - HTTP cache & compression
# cache static resources for 1 day (86400 seconds)
spring.resources.cache.cachecontrol.max-age=86400
spring.resources.cache.cachecontrol.proxy-revalidate=true

# enable response compression
server.compression.enabled=true
server.compression.mime-types=text/html,text/css,application/javascript,application/json
server.compression.min-response-size=1024

After enabling, browsers cache static files, reducing bandwidth and cutting CDN costs by about 30%.

4. Switch to Undertow for a lighter web container

Undertow is a lightweight, high‑concurrency NIO‑based server that uses less memory than Tomcat. Replace Tomcat with Undertow:

Undertow’s lower memory footprint and higher throughput make it ideal for IO‑intensive microservices.

5. Use a connection pool (HikariCP) for the database

Frequent creation and destruction of DB connections adds latency. HikariCP provides fast, reliable pooling. Example configuration:

# application.properties - HikariCP pool
spring.datasource.hikari.maximum-pool-size=20 # adjust to DB capacity
spring.datasource.hikari.minimum-idle=5
spring.datasource.hikari.connection-timeout=30000 # ms

After enabling the pool, connection acquisition time became negligible and query speed improved.

6. Tune JVM startup parameters

Set the initial and maximum heap size to the same value to avoid costly heap expansions and frequent GC pauses:

java -Xms1024m -Xmx1024m -jar your-application.jar

In IDEA, add -Xms1024m -Xmx1024m to VM options. This simple change reduced GC frequency by 60% and eliminated noticeable pauses.

Applying these six measures—thread‑pool tuning, async processing, HTTP caching, Undertow, HikariCP, and JVM memory tuning—reduced the e‑commerce API’s average response time from over 5 seconds to under 1.5 seconds, a >70% improvement, eliminating user complaints and stabilizing the system.