빌드한 JAR 파일을 확인해 보니, Undertow를 사용한 경우 예상외로 용량이 더 큰 것으로 나타났다. 이것은 의존성의 크기 차이 때문이다. Undertow를 사용하면 Tomcat과는 다른 의존성이 포함된다. Undertow 관련 라이브러리나 플러그인이 Tomcat 보다 더 많은 용량을 차지할 가능성이 있기 때문이다. 필요하지 않는 라이브러리를 제거하여 더 줄일 수 있다. 하지만 약 1MB 차이는 크게 문제되지 않기 때문에 변경하지는 않았다.
단, 필요한 경우 일부 라이브러리를 제거할 수 있다는 점을 알아야 한다.
간단한 String을 반환하는 기능에 부하 테스트를 진행하였다.
@RestController
public class TestController {
@GetMapping("/test1")
public String testResponse() {
for (int i = 0; i < 10000; i++) {
System.out.println("hello world");
}
return "response";
}
// 생략
에이전트별 가상 사용자를 1000 과 3000 두 상황을 나눠 테스트를 진행하였다.
초당 트랜잭션 횟수. 즉, 초당 몇 개의 트랜잭션을 처리할 수 있는가 (높을 수록 좋음)
서버가 요청에 대해 응답하는데 걸린 시간 평균 (낮을 수록 좋음)
초당 트랜잭션 횟수. 즉, 초당 몇 개의 트랜잭션을 처리할 수 있는가 (높을 수록 좋음)
서버가 요청에 대해 응답하는데 걸린 시간 평균 (낮을 수록 좋음)
이번 테스트를 통해 간단히 WAS 서버를 Tomcat에서 Undertow로 변경했을 뿐인데, 두 서버 간의 성능 차이가 상당히 크다는 것을 확인할 수 있었다. 가상 사용자를 3000으로 설정한 테스트 환경에서 Undertow는 TPS 면에서 Tomcat을 크게 상회하였으며, 사용자 수가 늘어남에 따라 그 격차는 더 두드러졌다. 반면, 평균 응답 시간 측면에서도 Undertow는 사용자 증가에 따라 안정적인 응답 속도를 유지하는데 뛰어난 성능을 보여주었다.
이러한 결과는 Undertow가 고성능과 경량화를 목표로 설계된 비동기 기반 WAS라는 점에서 비롯된 것으로 보인다. 특히 Tomcat은 기본적으로 스레드 기반 처리 모델을 사용하는 반면, Undertow는 비동기 I/O를 사용하여 리소스 효율성을 극대화한다는 차이가 주요 요인이라고 생각한다.
이번 테스트를 통해 Undertow가 높은 부하 환경에서도 안정적이고 뛰어난 성능을 제공한다는 것을 직접 증명하였다.