부하테스트를 이용한 Caching 성능 테스트 (with Jmeter)

이전에 Ngrinder를 이용해 부하테스트를 진행해본 적이 있다. Naver에서 제작한 오픈 소스 툴이라서 비교적 아시아권에서 많이 사용하는 느낌이었다. 이로 인해 참고할 문서가 많은 편은 아니었고 문제를 해결하는 데에 꽤 많은 시간이 필요했다. 뿐만 아니라 Ngrinder는 부하테스트 데이터들을 `.csv`파일로 제공하는데 매번 열고, 닫으며 관리하는게 조금 귀찮았다.

 

그래서 이번에는 Jmeter를 사용해보고자 한다. Jmeter는 Apache에서 제작한 Java 기반의 오픈 소스 툴이다.

구글 검색 트렌드만 보더라도 Ngrinder와 비교가 되지 않는다. 그 말은 레퍼런스가 훨씬 많다는 것이다. 뿐만 아니라 Jmeter는 swing으로 만들어진 GUI 툴 내에서 데이터를 한번에 확인할 수 있다. 더 자세한 내용은 천천히 살펴보도록 하자.

 

Jmeter 설치 및 실행

설치

하단의 링크에 들어가면 Binaries 파일과 Source 파일이 제공되는데 수정해서 사용할 것이 아니라면 Binaries 파일을 받으면 된다.

Apache JMeter - Download Apache JMeter

 

Jmeter를 실행하기 위해서는 Java 8버전 이상이 필요한데 넘어가도록 하겠다.

 

실행

실행은 Mac을 기준으로 다음 명령어를 통해 jmeter.sh 파일을 실행해주면 된다.

$ sh apache-jmeter-{VERSION}/bin/jmeter.sh

테스트 세팅

• 테스트 환경: Mac M1 Max / RAM 64GB / SSD 1TB 
• 테스트 시나리오: 10명의 사용자가 10초간 홈페이지`localhost:8080`조회
• 테스트 목적: 홈페이지에 걸려있는 Cache 성능과 안정성 검증

1단계. Thread Group 구성

부하 테스트는 가상 사용자를 구성해 서버에 요청하는 방식이며 Thread가 가상 사용자 역할을 담당한다. 다시 말해 Thread Group을 구성해야 하고 Jmeter에서 제공하는 옵션은 총 4가지이다.

 

• Open Model Thread Group: 특정 테스트 케이스에 실행될 사용자 풀과 스케줄(패턴)을 정의하면 스케줄에 따라 사용자가 생성되면서 테스트하는 옵션이다. (아직 실험적인 옵션으로 배포 과정에서 변경될 수 있다고 한다.)
• Setup Thread Group: 본 테스트를 수행하기 전에 초기화 작업을 수행할 사용자 풀을 정의하는 옵션이다.
• Thread Group: 특정 테스트 케이스에 실행될 사용자 풀, (모든 스레드를 시작하는 데에 걸리는) 램프업 시간, 테스트를 수해할 횟수 혹은 시간을 정의해 테스트하는 옵션이다.
• Teardown Thread Group: 본 테스트를 수행한 이후에 클린 작업을 수행할 사용자 풀을 정의하는 옵션이다.

단순히 페이지를 조회하는 테스트이기 때문에 Thread Local 옵션을 다음과 같이 세팅해줬다.

 

• Numbers of Threads: 10명의 사용자
• Duration: 10초동안
• Action ... Sampler error Continue: 에러가 발행해도 계속 요청

2단계. Sampler 구성

사용자를 구성했으니까 사용자의 행동을 정의할 차례이다. Jmeter에서는 Sampler 세팅으로 행동을 정의할 수 있다. 다양한 옵션들을 지원하는데 웹 요청에 대한 테스트는 Http Request를 사용한다.

 

3단계. Listener 구성

Sampler에 정의한 패턴대로 사용자가 요청을 하면 결과에 대한 데이터를 받아와야 한다. Listener가 그 역할을 수행한다.

 

Listener도 종류가 굉장히 많으니 자세한 내용은 공식 문서를 참고하길 바란다.

 

4단계. Assertions 구성

추가적으로 Sampler가 요청을 수행하고 받은 응답 결과에 대한 자세한 검증이 필요할 수 있다. 예를 들어 특정 리소스를 요청했는데, 의도치 않게 로그인이 되지 않아서 3XX 상태 코드와 함께 로그인 페이지로 리다이렉트하는 상황을 생각해보자. 상태 코드는 실패를 의미하지 않지만 서버 로직상 실패를 의미하는 경우에는 별도의 검증을 통해 실패로 처리해야 한다. 이 때 Assertions를 통해 검증 절차를 추가할 수 있다. (홈페이지에 조회에 대한 테스트에서는 굳이 필요하지 않으므로 생략하도록 하겠다.)

 

테스트 결과

위에서 언급한 시나리오와 목적대로 "캐싱을 미적용한 상황"과 "캐싱을 적용한 상황"으로 나눈 뒤, 동일한 조건으로 각각 10번의 테스트를 진행했다. 모든 테스트에서 비슷한 양상을 띄었기 때문에 10개의 표본 중 하나를 가져와 결과를 분석해보겠다.

캐싱 미적용

캐싱 적용

결과 분석

가장 눈여겨볼 부분은 "표본 수"와 "처리량"이다. 캐싱을 미적용한 경우 4316개의 요청을 처리했고, 초당 431.1의 처리량을 보였다. 반면, 캐싱을 적용한 경우 7060개의 요청을 처리했고, 초당 708.8의 처리량을 보였다. 결과적으로 캐싱을 적용했을 때 약 70퍼센트의 성능 향상을 보임을 알 수 있었다.

 

참고로 캐싱을 적용과는 무관하게 10개의 스레드가 처음 요청할 때의 처리시간이 유독 긴 것을 확인할 수 있는데, 이는 Ramp-up 시간을 1초로 설정해뒀기 때문이다. Ramp-up 시간을 지정하는 이유는 실제 사용자가 시스템에 접속하는 것을 모방하고, 부하를 점진적으로 증가시키기 위함이다.

---

아래 내용은 Jmeter 사용과 직접적인 관련이 없으므로 스킵하셔도 됩니다.

이슈. CodeCache is full

테스트를 진행하는 과정에서 이슈를 발견했다.

 

먼저 CodeCache란 무엇일까? JVM의 경우 JIT 컴파일러를 통해 자주 사용되는 바이트 코드를 기계어로 변환해 캐싱하는데, 이를 CodeCache라고 한다. 에러 메세지를 보면 CodeCache의 크기는 약 48MB로 설정돼 있는데 부하테스트를 통해 트래픽이 한번에 몰리면서 CodeCache가 3KB를 제외하고 가득찬 상태이다.

 

기본적으로 CodeCache는 JVM 내부 메커니즘에 의해 관리된다고 한다. 따라서 문제를 해결하기 위해서는 ReservedCodeCacheSize 옵션을 통해 CodeCache 크기를 늘려줘야 한다.