모든 Area 조회 api에 대한 궁금증

[Combi153]

#534 (review)

리오가 모든 행정구역(Area) 조회 api를 만들어서 배포했다.

해당 기능의 정상 동작을 확인하기 위해 swagger 로 api 요청을 날려보았다. 정상적으로 동작하는 것을 확인할 수 있었다.

그런데 로그를 살펴보다 이상한 점을 발견했다.

첫 번째로 모든 행정구역 조회 요청을 보냈을 때는 1122ms 가 걸렸다. 그러나 이후 요청에 대해서는 시간이 점차 짧아지더니, 10배 이상 축소됐다.

애플리케이션을 껐다가 다시 실행했을 때도 비슷한 양상이었다. 첫 번째 요청을 보냈을 때는 886ms 가 걸렸는데, 이후 요청에 대해서는 시간이 점차 짧아졌다.

왜 이런 일이 발생하는 것일까?

누군가 캐싱을 수행하기 때문일까? 영속성 컨텍스트? DB?

캐싱을 했다 치더라도 요청 수행 시간이 점진적으로 짧아지는 이유는 무엇일까?

[greeng00se]

예전에 제가 경로 이미지 요청했을 때도 같은 현상이 발생했습니다.
저희 따로 캐싱 설정을 한 곳도 없어서 제가 생각하기에 JVM 때문에 그런 것 같은데요.

해당 부분에 대한 참고 링크 및 글 남겨두겠습니다.
추가적으로 관련 키워드 JVM Warm Up

새로운 JVM 프로세스가 시작될 때마다 애플리케이션에 필요한 모든 클래스는 ClassLoader의 인스턴스에 의해 메모리에 로드된다. 이러한 Load 프로세스는 다음과 같이 3단계로 진행된다.

Bootstrap Class Loading : Java 코드와 java.lang.Object 와 같은 필수 클래스를 메모리에 로드함
Extension Class Loading : java.ext.dirs 경로에 있는 모든 JAR 파일을 로드함(개발자가 수동으로 JAR을 추가하는 경우)
Application Class Loading : 애플리케이션 클래스 경로에 있는 모든 클래스를 로드함
이때 중요한 것은 이러한 초기화 프로세스가 지연 로딩(LAZY LOADING) 방식을 기반으로 한다는 것이다.

클래스 로딩이 완료되면 애플리케이션 프로세스 시작과 동시에 필요한 중요한 클래스가 JVM 캐시로 푸시 되어 런타임 중에 빠르게 액세스가 가능한 것이고. 이를 제외한 다른 클래스들은 애플리케이션 프로세스가 실행 중일 때 실제 요청이 발생되어야만 로드된다.(per-request basis)

따라서 스프링 프레임워크와 같이 Java 웹 애플리케이션의 첫 번째 요청의 응답이 평균 응답 시간보다 훨씬 느린 이유는 위와 같이 JVM 아키텍처가 지연 클래스 로딩과 JIT 컴파일로 이루어져 있기 때문이다.

참고 자료
https://devwithpug.github.io/project/randhand-4-jvm-warmup-on-spring-cloud-msa/

[greeng00se]

추가적으로 해당 부분은 동일한 응답을 반환하기 때문에 원한다면 Caffeine 같은 로컬 캐시를 적용하는 것도 고려해보면 좋을 것 같아요!

[Combi153]

https://hudi.blog/jvm-warm-up/

위 블로그 글 좋네요.

‘java 클래스는 Lazy Loading 으로 메모리에 적재된다’, ‘JVM은 자주 실행 되는 코드를 컴파일하고 캐시한다’

두 가지를 기억하면 될 것 같습니다!