제이미터(JMeter)로 테스트 환경 구성 및 테스트하기_1

 

JMeter 세팅과 관련해서는 해당글을 참고하면 됩니다.

2024.03.22 - [개발] - 제이미터(JMeter)로 테스트 세팅 및 사용법 정리.

제이미터(JMeter)로 테스트 세팅 및 사용법 정리.

 

 

이번에 Jmeter를 사용한 부하테스트 또는 API서버의 성능테스트를 해야 할 일이 생겼다. ㅠ

현재 운영중인 API 서버에서 특정시간에 많은 수의 요청이 몰리면서 처리속도가 늦어지는 듯한 모습이 발생했고, 그에 따라서 WAS의 처리속도 향상을 위해 어디가 느린지(병목지점) 확인 후 튜닝을 하든지 처리를 하든지 해야했다.

대략적으로 확인해본 결과 API서버상의 요청은 1시간 기준으로 대략 16만건 정도가 들어왔고,
1분 단위로 파악했을때 평균적으로 2800건 언저리 최대로 들어온 경우에는 1분에 4천건 정도가 왔었는듯 보였다.

운영서버의 실질적인 모습과 스펙은 대략적으로 다음과 같았다.

웹서버의 경우 2core 4G

API서버의 경우 2core 8G

DB서버의 경우 4core 32G

 

해당 상황 발생시 로드밸랜서의 설정이 Src IP Hash 으로 지정되어 있어서 제대로 로드밸런싱이 안되는듯 했다.

(상황인지 후 급하게 Round Robin으로 처리했다. 한쪽 API서버에만 몰리는 현상이 발생했었음.)

현재 운영중인 API 서버에서 특정시간에 많은 수의 요청이 몰리면서 처리속도가 늦어지는 듯한 모습이 발생했고, 그에 따라서 WAS의 처리 속도 향상을 위해 어디가 느린지(병목지점) 확인 후 튜닝을 하든지 처리를 하든지 해야했다.

대략적으로 확인해본 결과 API서버상의 요청은 1시간 기준으로 대략 16만건 정도가 들어왔고, 1분 단위로 파악했을때 평균적으로 2850건 언저리 최대로 들어온 경우에는 1분에 4300건 정도가 왔었는듯 보였다.

이 경우 일단 한쪽에 몰리는것을 감안하더라도 최소 2850건에서 최대 4300건까지의 처리가 정상적으로 되었어야지만 해당 상황에서 문제가 발생하지 않는것으로 바라보았다.

고려한 상황

웹서버 → 톰캣 → DB 중 어디에서 병목현상이 발생한건지 확인을 해야했고, 실질적으로 수행된 쿼리는 평상시에 슬로우쿼리로 확인되는 대상이 아니였다.

그리고 웹서버에서 톰캣으로 mod_jk모듈을 사용하여 연결하는 형태였는데 톰캣에 요청을하고 응답을 못받아오는 형태의 로그가 많이 보여 톰캣에서 처리속도가 밀린다고 생각하고 접근하였다.

실질적으로 해당 톰캣에는 다른서버들과 다르게 maxThreads의 값을 30으로 지정하는 형태로 되어있는 부분도 있어서 속도에 관해서 문제가 발생 할 수도 있다고 생각했다(톰캣 8.5 버전을 사용중이라 아무런 설정이 없는 경우 default threads값은 200이다.)

테스트 대상으로는 가장 많은 요청이 들어올것 같은 것을 대상으로 하여 단순 조회를 기준으로 대상으로 선정했다.

테스트의 대상이 되는 서버 스펙

테스트의 경우

웹서버와 WAS를 분리하지않고 한곳에 둔 개발서버에서 진행했고 4core에 8G서버였고

DB서버는 별도로 불리된 개발DB인 2core에 8G 서버로 테스트했다.

(DB서버의 스펙이 조금 딸리긴 했지만 WAS가 문제란 가정으로 접근한 상태라..최초에는 신경쓰지 못했다.)

1차 테스트

테스트를 여러가지 조건을 막 바꿔가며 중구난방으로 하던때라… 보기도 어렵고 정리하기도 어려웠다.

해당 지표값은 Jmeter에서 제공하는 지표로써 2300건의 요청을 1분에 걸쳐(60초) 동안 1회 수행하는 것을 기준으로 수행한 결과이다.(동접자 1분내에 2300명 기준)

수행조건 수행날짜 평균(ms) 90%(ms) 95%(ms) 99%(ms) 에러(%) 처리속도(/sec)

 

수행조건	수행날짜	평균(ms)	90%(ms)	95%(ms)	99%(ms)	에러(%)	처리속도(/sec)
스레드 200개 DB max커넥션 15	2024-03-04	1865	3883	5039	8120	0.00	36.5
스레드 200개 DB max커넥션 15 keepAliveTimeout 3	2024-03-04	2152	4591	6191	10817	0.00	36.1
스레드 200개 DB max커넥션 15 keepAliveTimeout 3 maxKeepAliveRequests 50	2024-03-04	2031	4397	5681	8844	0.00	36.4
스레드 100개 DB max커넥션 15	2024-03-04	1852	3879	5181	7683	0.00	36.4
스레드 30개 DB max커넥션 15	2024-03-04	2069	3522	3760	4326	0.00	36.3
스레드 30개 DB max커넥션 15 maxKeepAliveRequests 50 keepAliveTimeout3	2024-03-04	1960	3276	4018	5367	0.00	36.4

 

정리.

평균적으로 걸린 시간은 대략 2초대이며 10%의 사용자들은 4초 1%의 사용자들은 늦으면 10초 빠르면 4초만에 응답을 받았다고 나왔다.

그러나 우리가 필요한 값은

1분 단위로 파악했을때 평균적으로 2850건 언저리 최대로 들어온 경우에는 1분에 4300건 정도가 왔었는듯 보였다.

최소한 저정도는 무리없게 처리가 되야하는 것이였다..

 

실질적인 테스트를 위한 정리.

처음에 Jmeter를 사용해서 테스트를 진행 할 때 테스트를 수행할 조건에 대해서 제대로 정리하지못해서 불필요한 요청을 하며 테스트 표본을 모았다고 판단하고 조건들에 대해서 정리를 시작했다.

다음글에서 계속....!