@ResponseStatus(HttpStatus.BAD_REQUEST) is 50 times less performant than @ResponseStatus(HttpStatus.UNAUTHORIZED)

[xiaochenxt]

version: springboot 3.5.4

@ResponseStatus(HttpStatus.BAD_REQUEST) is 50 times less performant than @ResponseStatus(HttpStatus.UNAUTHORIZED)

Interface hello QPS 1000-2000, interface hello2 QPS 40000-60000

Below is a simple code reproduction:

<dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
</dependency>

package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.http.HttpStatus;
import org.springframework.web.bind.annotation.*;

@RestControllerAdvice
@RestController
@SpringBootApplication
public class Demo1Application {

    public static void main(String[] args) {
        SpringApplication.run(Demo1Application.class, args);
    }

    @GetMapping("/hello")
    public String hello(){
        throw new ParamsErrorException("error");
    }

    @GetMapping("/hello2")
    public String hello2(){
        throw new Params2ErrorException("error");
    }

    public static class ParamsErrorException extends RuntimeException{
        public ParamsErrorException(String message){
            super(message, null, true, false);
        }
    }

    public static class Params2ErrorException extends RuntimeException{
        public Params2ErrorException(String message){
            super(message, null, true, false);
        }
    }

    @ResponseStatus(HttpStatus.BAD_REQUEST)
    @ExceptionHandler
    public String exceptionHandler(ParamsErrorException e) {
        return "error";
    }

    @ResponseStatus(HttpStatus.UNAUTHORIZED)
    @ExceptionHandler
    public String exceptionHandler(Params2ErrorException e) {
        return "error2";
    }

}

[bclozel]

I don't see why there should be a significant performance difference between the two in our codebase.
However, I can see a lot of reasons explaining that if you're running those benchmarks locally: JVM warmup, ports exhaustion, local noise, CPU throttling, etc.

Rather than discussing a particular (flawed) benchmark, we can reconsider this issue if you can provide profiling data that shows where CPU time is spent in one case versus the other.

[xiaochenxt]

I don't see why there should be a significant performance difference between the two in our codebase. However, I can see a lot of reasons explaining that if you're running those benchmarks locally: JVM warmup, ports exhaustion, local noise, CPU throttling, etc.

Rather than discussing a particular (flawed) benchmark, we can reconsider this issue if you can provide profiling data that shows where CPU time is spent in one case versus the other.

.Even after using Profiling, the time-consuming code was not found. Later, I removed tomcat and replaced it with undertow and jetty for testing, and there was no such issue. However, when switching back to tomcat, the problem reoccurred. The issue seems to originate from the internal tomcat container; it occurs as long as a 400 or 500 response is returned, while other status codes are not affected.

[bclozel]

Thanks for the update. I guess in this case you can try and report this to the Tomcat team.
I would suggest sending your profiler data and analysis rather than your benchmark results, as benchmarks are easily flawed.