nGrinder 성능 측정

Server Computer 환경

1차 테스트 환경(Ngrinder)

• 테스트 API : 포인트 적립(Row Lock을 걸었었다)
• agent : 1
• agent별 가상유저 : 100 ( 프로 세스 3, Thread 33 )
• Duration : 30초

1차 테스트 결과

• 4초경, TPS는 최고치를 경신했고 Byte현황을 보면 이후 0으로 수렴한다.
• 해당 현상은, 지속적으로 같은 데이터를 요청하다보니 해당 데이터를 Caching함으로써 발생하는 성능 이점이라고 볼수 있다.
• 지금 해보는 테스트의 단점이다. 지속적으로 다른 유저들에 대한 데이터를 넘겨야 한다.
• 하지만, 일단 단일 API로 같은 데이터로 발생했을때 발생하는 극한을 경험한다.

2차 테스트 환경(Ngrinder)

• 테스트 API : 포인트 적립(Row Lock을 걸었었다)
• agent : 1
• agent별 가상유저 : 150 ( 프로 세스 4, Thread 37 )
• Duration : 30초

2차 테스트 결과

• vUser 150까지는 잘 버틴다. 빨리 깨져라.

3차 테스트 환경(Ngrinder)

• 테스트 API : 포인트 적립(Row Lock을 걸었었다)
• agent : 1
• agent별 가상유저 : 200 ( 프로 세스 6, Thread 33 )
• Duration : 30초

3차 테스트 결과

• 드디어 고대하던 결과가 나왔다. 원인을 찾아보자.

agent console log를 보니 다음과 같은 에러를 볼수 있다. received a stop message란 키워드로 ngrinder github discussion에 검색해보자.

https://github.com/naver/ngrinder/discussions/886

"received a stop message" 와 함께 테스트가 종료되어버립니다. · Discussion #886 · naver/ngrinder

원인을 찾았다. 

해결하고 다시 실행해보자.

3차 테스트 환경(Ngrinder)

• 테스트 API : 포인트 적립(Row Lock을 걸었었다)
• agent : 1
• agent별 가상유저 : 200 ( 프로 세스 6, Thread 33 )
• Duration : 1분 30초

3차 테스트 결과

 

• 8초에서 12초 사이에 TPS 변동폭이 심하다.
• 지속적으로 TPS는 떨어지고, MEAN TEST TIME은 오르고 있다.
• 정확하게 알려면, 상세한 모니터링 도구가 필요하다.
• Scouter와 AWS의 모니터링 툴을 설치할 필요성이 있다.
• 일단 좀더 높은 환경을 계속 시도해보자.

4차 테스트 환경(Ngrinder)

• 테스트 API : 포인트 적립(Row Lock을 걸었었다)
• agent : 1
• agent별 가상유저 : 400 ( 프로 세스 6, Thread 33 )
• Duration : 2분

4차 테스트 결과

4차 테스트까지의 결과 피드백

비지속적으로 떨어지는 TPS, 지속적으로 오르는 Mean Test Time

• 지속적으로 TPS는 떨어지고, MEAN TEST TIME은 오르고 있다.
• 원인을 확정할수는 없지만, Spring MVC의 특성상 Request 요청시 Thread Pool에서 Thread를 가져오고 Overhead를 발생시키기에 그럴수 있다.
• Row 단위로 Lock을 걸어서 그럴수 있다.
• 하나하나 해결해보자.

Row Lock을 제외한 4차 테스트

변경포인트

기존의 경우 For Update문을 통한 Exclusive mode Lock을 걸었었는데, 해당 Lock을 제거해보았다.

• 확실히 Lock을 걸지 않으니, TPS와 처리량은 올라간 모습이다.
• 하지만, 미비하다.
• 테스는 여기까지 진행하고 개선 작업을 진행해보자.

어떤점을 개선할까?

개선하기 위해서는 4가지 방법이 있다고 생각한다.

• 기존의 프로그램 최적화(코드, 테이블 인덱스 등)
• 아키텍쳐 최적화( Scale Up이거나 Scale Out )
• 설계 최적화( 다 뜯어고친다. 지금같이 Point를 Lock 거는 방식에서 그냥 Point 이력만 바꾸는 식으로 )
• 구조를 최적화 ( Aws의 SQS를 활용한다든지의 방식 )

순서에 맞게 기존 프로그램 최적화를 진행하겠다.

그전에 해야 할 작업이 있다. 프로그램 어느 부분이 병목 현상이 걸리는지 파악해야 하는것이다.

모니터링 툴을 만들어야 할 필요성이 있다.

Scouter부터 시작한다.