[nGrinder] nGrinder설치 및 성능테스트 부하 테스트 사용법 (spring boot , tomcat)

nGrinder로 테스트를 해보자. 작성자의 경우 운영서버에 직접 돌렸으나 (아직 이용중이지 않은 서버이다.)


nGrinder 사용법은 중간부분부터 있습니다 거기서부터 보세요!


오픈되지 않은 서버에 직접 부하 테스트를 진행하였다. 오라클 클라우드 무료버전이기에 실제 출시 시 부하에 버틸 수 있는지 판단하기 위해 nGrinder를 사용하여 부하테스트를 진행하였다. 
현재 서버 상태를 먼저 확인하는 게 중요하니까, 아래 명령어를 실행하고 출력 결과를 확인하였다!

 

htop

 

 

CPU / 메모리 사용량 확인

df -h

 

 

 

 

디스크 사용량 확인

uptime

 

 

 

 

1. htop 결과 분석 (CPU, 메모리 상태)

출력 내용:

 

1 1.3% Tasks: 77 , 153 thr; 1 running 2 2.0% Load average: 0.00 0.00 0.00 Mem 507M/952M Uptime: 21:08:32 Swp 665M/2.00G

🔹 (1) CPU 사용량 (CPU Usage)

• 1.3%, 2.0% 사용 중 → 현재 CPU 사용량이 매우 낮음 (거의 대기 상태)
• 1 running → 실행 중인 프로세스가 1개뿐 (대부분의 프로세스는 대기 상태)

🔹 (2) Load Average (서버 부하율)

 

Load average: 0.00 0.00 0.00

0.00이면 거의 작업이 없는 상태

• Load Average(부하 평균) 값이 0.00, 0.00, 0.00 → CPU가 놀고 있다는 뜻
• 3개 숫자는 각각 1분, 5분, 15분 평균 부하율

부하율 기준

Load Average 값의미

0~1	안정적인 상태 (여유 많음)
1~2	적당한 부하 (멀티코어 서버라면 문제없음)
2 이상	CPU가 점점 밀리기 시작
4 이상	CPU 과부하 상태 (병목 발생 가능)

 

🔹 (3) 메모리 사용량 (RAM Usage)

 

Mem 507M/952M Swp 665M/2.00G

• RAM 총 952MB 중 507MB 사용 중 (약 53% 사용)
• Swap 메모리(가상 메모리) 2GB 중 665MB 사용 중 → 조금 주의 필요

Swap 사용량이 많다는 것은?

• RAM이 부족해서 디스크에 저장되는 Swap 공간을 많이 사용하고 있음
• 지금은 큰 문제는 아니지만, 부하 테스트를 하면 RAM이 모자랄 가능성이 있음
• 만약 RAM 사용량이 900MB 이상 계속 올라가면, Swap 과부하로 인해 서버가 느려질 수 있음

 현재는 큰 문제 없지만, 부하 테스트할 때 RAM 모니터링 필요! 

 

 

2. df -h 결과 분석 (디스크 상태)

출력 내용 (요약)

 

Filesystem Size Used Avail Use% Mounted on /dev/sda1 45G 14G 32G 30% / tmpfs 477M 243M 234M 52% /dev/shm

디스크 총 용량: 45GB
사용 중: 14GB (30%)
남은 공간: 32GB (여유 많음)

현재 디스크 공간은 충분히 여유가 있음

 

 

3. uptime 결과 분석 (서버 가동 시간 & 부하율)

출력 내용

 

14:03:48 up 21:12, 1 user, load average: 0.08, 0.02, 0.01

(1) 서버 가동 시간 (Uptime)

 

up 21:12

• 서버가 21시간 12분 동안 실행 중
• 리부팅한 지 하루도 안 됨 → 방금 설치한 서버일 가능성 높음

(2) 부하율 확인

 

load average: 0.08, 0.02, 0.01

• 1분 평균 부하율: 0.08 / 5분 평균: 0.02 / 15분 평균: 0.01
• 부하 거의 없음 → 서버는 거의 쉬고 있는 상태 

 

 

최종 결론: 지금 상태에서 부하 테스트 진행 가능!

 현재 서버 상태를 종합적으로 분석하면
CPU 사용량 2% 미만 (부하 거의 없음)
RAM 사용량 50% 수준이지만, Swap이 조금 사용됨 (테스트 시 주의 필요)
디스크 공간 충분 (45GB 중 14GB 사용, 32GB 남음)
부하율 0.08 (아주 낮음, 서버가 거의 쉬고 있음)

 현재 상태에서는 부하 테스트를 진행해도 문제가 없을듯 했다.
단, 부하 테스트 중 RAM 사용량이 900MB 이상 올라가면 Swap이 과부하될 가능성이 있으니 htop을 켜놓고 모니터링하면서 테스트하는 게 좋을듯 싶다.

 

 

지금부터 nGrinder 사용법을 설명하겠다 위에 글은 무시하시고 아래부타 따라하시면 된다..

 

 

https://github.com/naver/ngrinder/releases

 

위 링크에서 war파일을 다운받은 후 C드라이브에 ngrinder폴더를 만든 후 그 안에 war파일을 넣고 window PowerShell을 연다.

 

 

 

잘 들어가있는거 확인.

 

 

nGrinder는 내부적으로 Spring Boot 기반으로 동작한다.
그래서 java -jar ngrinder-controller-3.5.7.war를 실행하면 Spring Boot 서버가 실행되는 것처럼 로그가 나오게 된다.

 

java -jar ngrinder-controller-3.5.7.war를 입력하여 ngrinder를 실행하자.

 

 

위와같이 뜬다면 실행이 된것이다. 8080포트가 이미 돌고있다면 끄고 실행하길 추천한다. 에러뜬다.

 

웹 브라우저에서 아래 주소를 입력해서 접속

http://localhost:8080

 

 

 

 

 

웹 브라우저에서 아래 주소를 입력해서 접속

http://localhost:8080

로그인 (기본 계정)

• ID: admin
• PW: admin

만약 http://localhost:8080이 안 열리면?

1. java -jar 실행한 PowerShell 창에서 오류 메시지가 있는지 확인
2. netstat -ano | findstr :8080 명령어 실행 → 8080 포트가 사용 중인지 확인
3. 다른 프로그램 (예: Tomcat, XAMPP 등)이 8080 포트를 사용하고 있으면 충돌이 날 수 있음.
   • 이 경우 java -jar ngrinder-controller-3.5.7.war --server.port=9090처럼 다른 포트(9090)에서 실행 가능

 

admin에서 agent 다운로드

다운로드 완

 

➡ 다운로드 후 압축을 푼다 반디집 알집 등으로 알아서 푸시오.

 

 

 

 

 

풀면 이렇게 된다.

 

실행코드 : .\run_agent.bat -ch localhost

 

위 사진처럼 새 윈도우쉘을 열고 agent를 실행한다.

 

현재 Agent가 정상적으로 실행되었고, Controller(localhost:8080)에 연결된 상태이다.

 

 

Agent가 제대로 등록되고 연결된게 확인되며 State는 Ready상태로 되어있는것을 확인한다면 이제 script를 작성하자.

 

create버튼을 눌러 생성창을 연다.

 

 

script Name : 파일명 (아무거나 넣으세요)

URL to be tested : 테스트할 API 넣으시오 

create 버튼을 누르면 자동으로 소스코드가 자동으로 생성된다.

 

 

 

 

 

다음 단계: 부하 테스트 설정

지금은 단일 요청만 테스트했는데, 이제 부하 테스트 설정을 조정해보자.

🔹 부하 설정 방법 (Test Configuration)

1. nGrinder 웹 UI에서 테스트 스크립트를 선택하고 "Create Test" 버튼 클릭
2. 테스트 설정 화면에서 아래와 같이 값을 조정:
   • Thread (동시 사용자 수): 10 ~ 50 (초기 테스트 시 10부터 시작)
   • Processes (에이전트 개수): 1 (로컬 실행이므로 1개만 사용)
   • Test Duration (테스트 지속 시간): 1 ~ 3분 (짧게 설정)
   • Ramp-up Time (점진적 증가 시간): 10초 (갑작스럽게 부하 증가 방지)
   • Test Mode: "Normal Test" (처음에는 기본 테스트 모드 사용)
3. "Start Test" 버튼 클릭하여 부하 테스트 실행
4. Dashboard에서 부하 테스트 진행 상황 모니터링

 

테스트 전략

• 초기: Thread 10, 1분 테스트 → 부하가 증가해도 정상 응답이 오는지 확인
• 중간: Thread 30~50, 3분 테스트 → 서버가 어느 정도 버틸 수 있는지 확인
• 고부하: Thread 100+ → 서버가 한계점에서 어떻게 반응하는지 확인

 

 

 

 

 

 

서버가 무료버전이라 그런가 평균 API응답이 4초나 걸린다.. 부하를 낮추고 다시 테스트한 결과

 

 

 

 

 

 

 

nGrinder 용어 정리

TPS(처리량)란?

• TPS는 "Transactions Per Second"의 약어로, "초당 처리가능한 트랜잭션의 수"
• TPS가 100이라면 초당 처리 할 수 작업이 100이다라고 생각하면 된다.
• TPS 수치가 높을수록 짧은 시간에 많은 작업을 처리할 수 있다고 보면 된다.

Vuser란?

• 가상 사용자(Virtual User)
• ex) "vUser 50"은 가상 사용자(Virtual User)가 50명을 나타낸다. 이것은 부하 테스트 시나리오에서 50명의 가상 사용자가 동시에 시스템 또는 애플리케이션에서 동작하고 있다는 것을 의미한다.

• TPS: 평균 TPS
• Peak TPS: 최고 TPS
• Mean Test Time: 평균 테스트시간
• Executed Tests: 테스트 실행 횟수
• Successful Tests: 테스트 성공 횟수
• Errors: 에러 횟수
• Run time: 테스트 실행시간

 

부하 테스트 결과 분석

이번 실행에서는 API 요청이 1,577번 발생했다

 

1. 부하 테스트 설정 vs. 실행 결과

항목설정 값의미

Total Vusers	20	동시에 실행되는 가상 사용자 (Vuser) 수
TPS (Transactions Per Second)	28.0	초당 평균 28개 요청 발생
Peak TPS	33.0	순간 최대 초당 33개 요청 발생
Mean Test Time	703.69ms	1회 요청당 평균 0.7초 소요
Executed Tests	1,577	총 API 요청 횟수
Successful Tests	1,577	정상적으로 응답 받은 요청 수
Errors	0	오류 발생 없음
Run time	1분 (60초)	총 실행 시간

 

2. 요청 수 계산 (왜 1,577번 실행됐을까?)

우리가 실행한 설정을 공식으로 풀어보면 다음과 같아.

1. TPS (초당 요청 수) × 실행 시간(초) ≈ 총 요청 수
   • 28.0 TPS × 60초 ≈ 1,680
   • 실제 실행된 1,577번 요청과 거의 일치
     → 정상적인 실행임.
2. Vuser(가상 사용자) 영향
   • Vuser가 20명이었기 때문에,
   • 각 사용자당 (1577 ÷ 20) ≈ 78번 요청을 실행한 것.

 

3. 성능 분석 및 조정 방법

(1) 성능이 괜찮다면?

• 현재 평균 응답 속도 703.69ms
• TPS가 28인데도 오류가 0개
  즉, 서버가 현재 부하를 잘 버티고 있음

(2) 부하를 더 높이려면?

• Vuser(가상 사용자) 수를 30~50으로 증가
• Duration(실행 시간) 2~5분으로 늘리기
• Threads 개수 늘려서 동시 요청 증가
• Ramp-Up을 사용해서 점진적 증가 적용