어떻게 하면 Http api의 응답속도가 느려질까?

웹, 앱 플랫폼으로 개발하시는 분들은 여러 가지 이유로 postman을 통해 api를 실제로 실행을 해봅니다. 보통은 http 응답코드가 의도한 데로 나오는지 확인하고 끝내는 것이 일반적이긴 한데요.

그런데 한 가지 의문이 듭니다. 같은 api를 실행할 때 처음 실행했을때와 그 이후에 실행했을 때와의 응답속도 차이가 거의 10배 이상 차이가 납니다. 구글링을 해봐도 딱 명쾌하게 답을 주는 경우가 거의 없습니다. 물론 이 원리를 몰라도 개발을 하는데 전혀 문제가 없습니다. 그러나, 개발 프로젝트의 규모가 커지고 MAU가 증가할 경우 성능 최적화가 필수이며 최적화 작업을 하기 위해선 내가 사용하는 api의 동작원리를 제대로 파악할 필요가 있습니다.

HTTP 통신의 응답속도를 늦추는 요인

1. 네트워크 관점

1.1. TCP Slow Start

TCP 연결은 처음에 데이터 전송 속도를 낮추고, 패킷 손실 없이 안정적으로 전송할 수 있는 한도를 찾아가면서 점진적으로 속도를 높입니다. 이렇게 점진적으로 속도를 높이는 프로세스를 'Slow Start'라고 합니다. 최초 요청에서는 이 Slow Start 단계를 거치기 때문에 속도가 비교적 느릴 수 있습니다. 반면, 이후 요청에서는 이미 연결이 확립되어 있고, 적절한 전송 속도를 알고 있기 때문에 빠르게 데이터를 전송할 수 있습니다.

1.2. TCP Connection Reuse

HTTP/1.1부터는 기본적으로 'Keep-Alive' 연결을 사용합니다. 이는 한 번 연결된 TCP 연결을 재사용하므로, 각 요청마다 연결을 새롭게 생성하고 해제하는 비용을 줄일 수 있습니다. 최초 요청에서는 TCP 연결을 새롭게 생성하는 비용이 발생하지만, 이후 요청에서는 이 연결을 재사용합니다.

2. 애플리케이션 관점(Spring boot)

2.1. JVM Warm-up

JVM (Java Virtual Machine)은 최적의 성능을 위해 코드를 실행하는 동안 여러 가지 최적화를 수행합니다. 예를 들어, JIT (Just-In-Time) 컴파일러는 코드가 반복적으로 실행되는 경우, 더 효율적인 기계 코드로 컴파일하여 실행 속도를 향상시킵니다. 따라서, 처음 요청을 처리하는 동안에는 이러한 최적화가 아직 완료되지 않았을 수 있으며, 이후 요청에서는 이 최적화의 이점을 볼 수 있습니다.

2.2. 스프링 애플리케이션 컨텍스트와 빈 초기화

스프링 부트 애플리케이션은 처음으로 요청을 받았을 때 일부 빈을 생성하거나 초기화할 수 있습니다. 이 초기화 작업은 약간의 지연을 초래할 수 있으며, 이후 요청에서는 이 빈을 재사용하므로 더 빠른 응답 시간을 기대할 수 있습니다.

3. 그 외...

데이터베이스 연결 풀링, OS 레벨에서의 파일 시스템 캐싱 등.... 매우 많습니다만, 웹/앱 개발자 입장에서는 이 사실을 알아도 해결할 수 있을만한 요소가 아닌 듯하여, 자세히 다루진 않겠습니다. 다만 이러한 요소들도 HTTP 통신을 늦추는 요소가 되는구나 하는 생각을 가지며, 코드를 작성할 때 참고만 해두면 좋을 것 같습니다.