sendWarmUpRequest 한번 호출해 놓으면 왜 빨라질까?

WebClient를 통해 API 호출을 한 번 수행하면 이후 요청이 더 최적화될 수 있습니다. 이 최적화는 주로 커넥션 풀링과 DNS 조회 최적화에서 발생합니다. 아래에서 각 최적화가 어떻게 이루어지는지 설명드리겠습니다.

1. 커넥션 풀링(Connection Pooling)

커넥션 풀링은 클라이언트(예: WebClient)와 서버 간의 네트워크 연결을 재사용하여 성능을 최적화하는 방법입니다. 다음은 커넥션 풀링이 어떻게 이루어지는지에 대한 설명입니다:

• TCP 연결 재사용:
  • WebClient는 HTTP 요청을 보낼 때 TCP 연결을 사용합니다. 이 TCP 연결은 설정하는 데 일정한 오버헤드(예: 3-way handshake)가 필요합니다.
  • 첫 번째 요청이 발생하면 WebClient는 서버와의 TCP 연결을 설정합니다. 이 연결이 성공적으로 맺어지면, WebClient는 이를 "커넥션 풀"에 저장해둡니다.
  • 이후 동일한 서버로 요청을 보낼 때, WebClient는 기존의 연결을 재사용할 수 있습니다. 이로 인해 새로운 TCP 연결을 설정하는 오버헤드가 제거되어, 요청의 처리 속도가 빨라집니다.
• Keep-Alive:
  • HTTP/1.1부터 기본적으로 "Keep-Alive" 헤더가 활성화되어 있습니다. 이 헤더는 연결을 일정 시간 동안 열어두고, 추가적인 요청에 대해 동일한 연결을 재사용할 수 있도록 합니다.
  • 이렇게 재사용된 연결은 동일한 서버로의 후속 요청에서 설정 오버헤드를 없애고 성능을 최적화합니다.

2. DNS 조회 최적화

DNS 조회는 도메인 이름을 IP 주소로 변환하는 과정입니다. 이 과정에서 최적화가 이루어지면 후속 요청의 처리 시간이 단축될 수 있습니다:

• DNS 조회 캐싱:
  • 클라이언트가 서버에 처음 연결할 때, 도메인 이름을 IP 주소로 변환하기 위해 DNS 조회가 발생합니다. 이 과정은 상대적으로 느릴 수 있지만, 한 번 조회된 DNS 정보는 일정 시간 동안 캐시됩니다.
  • 이 캐시는 운영 체제, JVM, 또는 WebClient 내부에서 관리됩니다. WebClient는 처음 DNS 조회를 수행한 후, 일정 기간 동안 동일한 도메인 이름에 대한 후속 요청이 있을 경우, 캐시된 IP 주소를 사용하여 DNS 조회 과정을 생략합니다.
  • 결과적으로, 이후 요청은 DNS 조회를 다시 수행할 필요가 없으므로 요청 처리 시간이 줄어들게 됩니다.

3. TLS 핸드셰이크 최적화 (HTTPS의 경우)

• TLS 세션 재사용:
  • 만약 HTTPS를 사용하여 연결을 설정하는 경우, TLS 핸드셰이크 과정에서 추가적인 오버헤드가 발생합니다. 그러나 TLS 세션이 설정된 후, 이 세션 정보가 일정 시간 동안 재사용될 수 있습니다.
  • WebClient는 동일한 서버로의 후속 요청에서 이 TLS 세션 정보를 재사용하여 핸드셰이크 과정을 최적화합니다. 이렇게 하면 암호화된 연결을 설정하는 오버헤드가 줄어들고, 성능이 향상됩니다.

요약

WebClient로 한 번 API를 호출하면 커넥션 풀링과 DNS 캐싱을 통해 다음과 같은 최적화가 이루어집니다:

1. 커넥션 풀링: 초기 TCP 연결이 설정된 후, 이 연결을 재사용하여 후속 요청에서 연결 설정에 필요한 시간을 절약합니다.
2. DNS 조회 최적화: DNS 조회 결과를 캐싱하여 동일한 도메인 이름으로의 후속 요청에서 DNS 조회를 생략함으로써 요청 처리 시간을 줄입니다.
3. TLS 세션 재사용(HTTPS): TLS 핸드셰이크를 최적화하여 암호화된 연결 설정 시간을 줄입니다.

 

---

 

1. 커넥션 풀링(Connection Pooling)

• 설명: 대부분의 HTTP 클라이언트(특히 WebClient)는 커넥션 풀을 관리합니다. 즉, 외부 서버에 처음 연결할 때 TCP 연결을 설정하고 이를 유지한 후, 후속 요청이 동일한 서버로 보내질 때 해당 연결을 재사용할 수 있습니다.
• 효과: sendWarmUpRequest를 사용하여 처음 API를 호출하면, 커넥션 풀에 서버와의 연결이 유지됩니다. 이후 동일한 서버로 요청을 보낼 때, 새로운 TCP 연결을 설정하는 데 필요한 시간이 절약되므로 요청 속도가 빨라집니다.

2. 캐싱(Caching)

• 설명: 서버나 클라이언트 쪽에서 결과를 캐시할 수 있습니다. 예를 들어, API 요청 결과가 클라이언트나 서버 쪽에서 캐싱된 경우, 동일한 요청이 반복되면 실제로 서버에 요청을 보내지 않고 캐시된 결과를 반환할 수 있습니다.
• 효과: API 결과가 캐시된다면, 이후 동일한 요청에 대해 빠르게 응답을 받을 수 있으므로 응답 시간이 단축됩니다. 물론, 캐싱이 활성화되었는지, 어떤 데이터가 캐시되는지에 따라 다릅니다.

3. JIT(Just-In-Time) 컴파일링 및 메서드 초기화

• 설명: JVM 기반 애플리케이션에서는 코드가 처음 실행될 때 바이트코드가 기계어로 변환되는 JIT 컴파일이 이루어집니다. 또한, 애플리케이션 내부적으로 첫 요청 시 여러 초기화 작업(예: 클래스 로딩, 메서드 초기화 등)이 수행됩니다.
• 효과: sendWarmUpRequest를 통해 API를 처음 호출하면, 이와 관련된 초기화 작업이 모두 완료됩니다. 이후 요청에서는 이러한 초기화 작업이 반복되지 않으므로, 해당 요청의 처리 속도가 빨라집니다.

4. 네트워크 경로 최적화

• 설명: 초기 요청에서 네트워크 경로가 설정되고, DNS 조회 등의 네트워크 초기화 작업이 수행될 수 있습니다.
• 효과: 초기 요청 이후에는 네트워크 경로가 최적화되어 다음 요청에서 네트워크 레이턴시가 줄어들 수 있습니다.

 

결론

sendWarmUpRequest를 통해 API를 한 번 호출하는 것이 이후 요청의 응답 속도를 개선할 수 있는 이유는 커넥션 풀링, 캐싱, JIT 컴파일링 및 초기화 작업, 네트워크 경로 최적화 등의 메커니즘이 작용하기 때문입니다. 이러한 작업들은 초기 요청에서 발생하지만, 이후 요청에서는 대부분 이미 준비된 상태이므로 응답 속도가 빨라집니다.

다만, 이 효과는 시스템의 설정 및 상황에 따라 다르게 나타날 수 있으며, 모든 경우에 적용되지는 않을 수 있습니다. 이 점을 고려하여 시스템 성능을 최적화할 때 참조할 수 있습니다.

 

---

 

Redis나 Oracle 같은 데이터베이스에 대한 초기 연결도 sendWarmUpRequest와 유사한 이유로 이후 요청이 빨라질 수 있습니다. 다만, 각각의 시스템이 작동하는 방식에 따라 차이가 있습니다. 아래에서 Redis와 Oracle의 초기 연결에서 이후 요청이 빨라질 수 있는 이유를 설명드리겠습니다.

1. Redis

Redis는 인메모리 데이터베이스로, 주로 빠른 데이터 액세스를 제공하기 위해 사용됩니다. 초기 연결 이후 요청이 빨라질 수 있는 주요 이유는 다음과 같습니다:

• 커넥션 풀링:
  • 설명: Redis 클라이언트 라이브러리(예: Lettuce, Jedis 등)는 일반적으로 커넥션 풀링을 지원합니다. 처음 Redis 서버에 연결할 때 TCP 연결이 설정되고, 이후 이 연결이 유지됩니다. 후속 요청은 이 연결을 재사용합니다.
  • 효과: 처음 연결 시 발생하는 TCP 핸드셰이크 및 인증 등의 오버헤드가 후속 요청에서 줄어들어, 이후 요청이 더 빨라질 수 있습니다.
• 초기화 작업:
  • 설명: Redis 클라이언트는 첫 연결 시 내부적으로 몇 가지 초기화 작업(예: 스레드 풀 설정, 파이프라이닝 등)을 수행할 수 있습니다.
  • 효과: 초기화 작업이 완료되면 이후 요청은 이러한 작업의 영향을 받지 않으므로, 초기화된 환경에서 더 빠르게 처리됩니다.

2. Oracle (JDBC 기반 데이터베이스 연결)

Oracle과 같은 관계형 데이터베이스의 경우, 초기 연결 후 요청이 빨라질 수 있는 주요 이유는 다음과 같습니다:

• 커넥션 풀링:
  • 설명: JDBC와 같은 데이터베이스 클라이언트는 일반적으로 커넥션 풀링을 사용합니다. 애플리케이션이 처음 데이터베이스에 연결할 때는 물리적 커넥션이 생성됩니다. 이후 이 커넥션은 풀에 저장되어 다음 요청에서 재사용됩니다.
  • 효과: 새로운 연결을 설정하는 대신 기존의 커넥션을 재사용함으로써, 후속 데이터베이스 쿼리 실행 속도가 빨라집니다.
• SQL 준비 및 캐싱:
  • 설명: Oracle은 자주 실행되는 SQL 쿼리를 캐싱할 수 있습니다. 특정 SQL 쿼리가 처음 실행될 때는 파싱, 최적화, 컴파일 등의 작업이 필요하지만, 이후 동일한 쿼리를 실행할 때는 캐시된 실행 계획을 재사용할 수 있습니다.
  • 효과: 초기 요청 후, 동일한 쿼리를 실행할 때 이러한 캐시 덕분에 더 빠르게 처리될 수 있습니다.
• JIT 컴파일 및 클래스 로딩:
  • 설명: JDBC 드라이버 및 애플리케이션 내에서 Oracle 관련 클래스가 처음 로드되고 JIT 컴파일이 발생합니다.
  • 효과: 이후 요청에서는 이러한 작업이 반복되지 않으므로, 처리 속도가 빨라질 수 있습니다.

결론

Redis나 Oracle과 같은 데이터베이스에 처음 연결한 후, 후속 요청이 빨라질 수 있는 이유는 주로 커넥션 풀링, 초기화 작업, SQL 캐싱(Oracle의 경우) 등의 이유와 관련이 있습니다. 이로 인해, 처음 연결 시 발생하는 오버헤드가 이후 요청에서는 발생하지 않거나 줄어들어, 전체적인 성능이 향상됩니다.

따라서, ResourceWarmupService에서 Redis와 Oracle에 대한 초기 연결을 수행하는 것은 후속 요청의 성능을 개선하는 데 긍정적인 영향을 줄 수 있습니다.

 

 

---

 

localhost를 호출하여 이후 요청이 빨라지는 현상은 주로 JVM 초기화 작업, 서블릿 컨테이너 초기화, 그리고 JIT 컴파일과 관련이 있습니다. 이러한 초기화 작업이 완료된 후에는 해당 애플리케이션이나 서블릿의 응답 속도가 빨라질 수 있습니다. 이를 다음과 같이 설명할 수 있습니다.

1. 서블릿 컨테이너 초기화

• 설명: 서블릿 컨테이너(예: Tomcat, Jetty 등)가 처음으로 요청을 처리할 때, 여러 가지 초기화 작업을 수행합니다. 여기에는 서블릿 객체의 생성, 필터 및 리스너의 초기화, 필요한 리소스 로드 등이 포함됩니다.
• 효과: localhost를 호출하여 애플리케이션의 특정 엔드포인트(예: /actuator/health)에 접근하면, 해당 서블릿이 로드되고 초기화됩니다. 이러한 초기화 작업이 완료되면, 이후 동일한 서블릿에 대한 요청이 처리될 때 초기화 작업이 다시 수행되지 않으므로 응답 속도가 빨라질 수 있습니다.

2. JVM 및 JIT 컴파일

• 설명: Java 애플리케이션이 처음 시작될 때, JVM은 초기화 작업을 수행하고, 자바 바이트코드를 네이티브 코드로 변환하는 JIT(Just-In-Time) 컴파일을 실행합니다. 이 과정에서 애플리케이션의 성능이 향상될 수 있습니다.
• 효과: localhost를 호출하면, 애플리케이션의 특정 부분이 처음으로 실행되어 JIT 컴파일이 이루어집니다. 이 초기화 작업이 완료되면, 이후 동일한 코드가 실행될 때는 이미 컴파일된 네이티브 코드가 사용되므로 실행 속도가 빨라집니다.

3. 애플리케이션 및 프레임워크 초기화

• 설명: Spring과 같은 프레임워크를 사용하는 애플리케이션은 처음 요청을 처리할 때 컨텍스트 초기화, 빈 생성, AOP 프록시 생성, 데이터베이스 연결 설정 등 다양한 작업을 수행합니다.
• 효과: localhost를 호출하여 애플리케이션이 이러한 초기화 작업을 마치면, 후속 요청은 이미 초기화된 환경에서 처리되므로 더 빠르게 응답할 수 있습니다.

4. 캐싱 메커니즘

• 설명: 애플리케이션의 특정 엔드포인트를 처음 호출하면, 해당 요청과 관련된 데이터나 객체가 메모리에 캐시될 수 있습니다. 이후 동일한 요청이 들어오면 캐시된 데이터를 활용해 빠르게 응답할 수 있습니다.
• 효과: 초기 요청에서 필요한 리소스가 메모리에 캐시된 후, 후속 요청이 캐시된 데이터를 사용하여 더 빠르게 처리됩니다.