LLM 호출 클라이언트를 고친 이유를 재현 실험으로 다시 확인했고, 그중 하나는 틀렸다
- TCP 연결 100 → 1개
- 요청당 8.0~9.1 → 2.1~2.3ms
문제 상황
개발 로그에는 LLM 호출 클라이언트를 고친 이유를 두 가지로 적었다. 요청마다 클라이언트를 새로 만든다는 점과, 연결 시간 제한이 없어 연결 단계에서 무한정 기다릴 수 있다는 점이다. 두 설명을 실험으로 확인한 적은 없었다.
해결 방안
수정 전과 수정 후의 클라이언트 구성을 Sureing과 같은 Spring 7.0.8로 옮겨, 연결을 받지 않는 주소와 정상 서버 100회 요청에서 비교했다. 원본 코드는 고치지 않았다.
결과
연결을 받지 않는 주소에서는 수정 전과 후 모두 약 8.0초에 실패했다. 이 버전의 setReadTimeout은 요청 전체 시간 제한이라 연결 단계까지 포함하므로, 무한 대기라는 설명은 기각했다. 정상 서버 100회 요청에서는 TCP 연결이 100개에서 1개 재사용으로, 요청당 시간이 8.0~9.1ms에서 2.1~2.3ms로 줄었다. 로컬 HTTP로 잰 값이라 실제 HTTPS LLM 호출의 차이는 재지 않았다.