기본적인 JMeter 스크립트 작성 후 요청 파라미터를 구성하고 난 후, 다음과 같은 문제들에 직면하게 되었다. 이를 해결하기 위한 실제 적용 사례와 최적화 전략을 정리한다.

1. 요청 서명(Signature) 검증 오류 해결

API 요청 시 인증을 위해 동적 서명이 필요한 경우, 정확한 서명 생성이 필수이다. 개발팀과 협의하여 서명 알고리즘과 필요한 파라미터를 확인했다.

서명 로직이 포함된 외부 라이브러리(XXXsign.jar)를 사용해야 하므로, 다음 절차를 수행:

1. 개발팀으로부터 제공받은 JAR 파일을 JMeter 설치 디렉터리의 /lib 폴더에 복사.
2. JMeter 재시작 후, 각 HTTP 요청 전에 서명을 생성할 수 있도록 Pre-Processor (BeanShell PreProcessor) 추가.

예제 코드:

import XXXsign.Openapi2sign;

// 필요한 파라미터 추출
String token = "user_token_value";  // 실제 토큰 값 또는 변수 참조
long timestamp = System.currentTimeMillis() / 1000;  // 초 단위 타임스탬프
String dataField = "12121";  // 개발사 지정 필드

// 서명 데이터 조합
String rawData = token + timestamp + dataField;

// 외부 라이브러리를 통한 MD5 서명 생성
String signature = new Openapi2sign().md5Encode(rawData);

// JMeter 변수로 저장하여 이후 요청에서 사용
vars.put("api_signature", signature);
    

HTTP 요청 헤더나 파라미터에서 ${api_signature} 형태로 값을 참조하면 된다. 디버그용으로 Debug Sampler를 삽입해 변수 값 확인 후, 본격 실행 시 제거하는 것이 좋다.

2. 쿠키 기반 세션 검증 우회 전략

대규모 동시 접속 테스트 시, 로그인 프로세스를 매번 수행하는 것은 비효율적이며 부하 원인이 될 수 있다. 따라서 고정된 쿠키 값을 활용한 세션 모킹 방식을 채택했다.

개발팀과 협의하여 Redis에 고정 세션 정보를 사전 등록:

• sid = {userId} + 'sid'
• uid = {userId}
• device_id = test (고정값)

JMeter 설정:

1. CSV Data Set Config를 사용해 다중 사용자 ID를 로드.
2. HTTP Cookie Manager에 정적 쿠키 항목 추가.
3. 쿠키 값 내 uid와 sid는 CSV에서 읽은 ${userId}로 동적 치환.

이 방식으로 로그인 없이도 유효한 세션 상태를 유지하며 API 호출 가능해졌다.

3. Windows 환경에서의 성능 병목 해소

로컬 머신(Windows 10)에서 테스트 시, 초기에는 초당 처리량이 낮고 에러율이 55% 이상 발생했다. 이를 해결하기 위해 시스템 및 JMeter 설정을 튜닝했다.

JVM 메모리 증가

JMeter 실행 스크립트(jmeter.bat) 내 JVM 힙 크기를 조정:

JVM_ARGS="-Xms1g -Xmx4g"
    

최대 4GB까지 할당하여 메모리 부족으로 인한 GC 지연 감소.

TCP 연결 제한 완화 (레지스트리 수정)

Windows 기본 TCP 포트 범위 및 TIME_WAIT 시간은 고부하 테스트에 적합하지 않다. 아래 레지스트리 값을 수정:

1) 클라이언트 임시 포트 범위 확장
경로: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
새 DWORD 값 추가: MaxUserPort = 65534 (10진수)

2) TIME_WAIT 상태 지속 시간 단축
동일 경로에 새 DWORD 값 추가: TcpTimedWaitDelay = 30 (초 단위, 10진수)

변경 후 시스템 재부팅 필요. 이 조치로 포트 고갈 현상이 크게 완화되었으며, 연결 재사용 주기가 단축되어 처리량 증가.

4. 단일 머신에서의 동시성 극대화 전략

시스템 리소스 튜닝 후에도 여전히 한계가 있다면, 테스트 스큼립트 자체를 효율화해야 한다.

• 스레드 수 조절: 각 스레드는 약 3~4MB 메모리를 소비함. 4GB 힙에서는 약 800~1000 스레드가 실질적 한계. 과도한 스레드는 컨텍스트 스위칭과 GC로 인해 성능 저하 유발.
• 런업 시간(Ramp-up): 500 이상의 스레드 사용 시, 30초 이상의 런업을 권장. 급격한 부하 발생은 네트워크 및 서버 과부하 유도.
• 모니터링 컴포넌트 비활성화: View Results Tree, Response Assertion 등은 디버깅 외에는 반드시 제거. I/O 및 메모리 사용량 급증.
• 정밀한 부하 제어: 특정 TPS 유지가 필요할 경우, Constant Throughput Timer 또는 Throughput Shaping Timer 사용.

최종적으로 위 조치들을 종합 적용한 결과, 처리량이 약 3배 이상 향상되었으며, 에러율은 5% 미만으로 안정화되었다.