.

nGrinder를 이용한 TPS, 응답시간 성능 테스트 리뷰

시스템 안정성 및 성능 평가 부하 테스트 jMeter, nGrinder와 같은 대표적인 도구를 먼저 살펴보고 배포하기로 했습니다.

쉬운 목차

J미터

  • Apache Software Foundation에서 개발한 Java 기반 오픈 소스 성능 테스트 도구입니다.
  • HTTP, FTP, JDBC 및 기타 프로토콜을 지원하고 GUI를 통해 테스트 계획을 만듭니다.
    JMeter는 강력한 그래픽 보고 및 분석 기능을 제공합니다.
  • 사용하기 쉽고 확장성이 뛰어남

n그라인더

  • 네이버가 자바 기반으로 개발한 오픈소스 성능 테스트 도구
  • JMeter 위에 구축되었으며 분산 시스템의 효율적인 테스트를 위한 기능을 제공합니다.
  • 강력한 분석 기능을 갖추고 있으며 스트레스 테스트, API 테스트 등 다양한 테스트 시나리오를 지원합니다.

JMeter는 여러 프로토콜을 지원하고 활용도가 높으며 가장 널리 사용되기 때문에 참고가 많이 되는 것 같습니다.
하지만 제 경우에는 실제 성능을 테스트하기보다 nGrinder가 더 강력한 프로파일링 기능을 가지고 있는데, 그 목적은 얼마나 많은 부하를 처리할 수 있는지, redis로 세션을 저장하는 기능이 얼마나 효과적인지, 성능 테스트 자체를 연구하는 것입니다.
위로 선택

이 글에서는 nGrinder 실행 방법은 생략하도록 하겠습니다.
그런데 nGrinder는 자바 11 버전까지 지원하기 때문에 자바 버전 변경에 애를 많이 먹었습니다.
하지만 덕분에 bash_profile 개념과 스크립팅 방법을 이해하게 되었습니다.

현재 내 응용 프로그램은 서버와 데이터베이스에서 로컬로 실행됩니다.
부하 테스트를 작성할 때 에이전트 수, Vuser(Process * Thread) 등을 설정할 수 있으며 한 대의 PC가 요청과 응답을 모두 담당합니다.
java.net.SocketException이 발생했습니다.
사실 Java에서 websocket을 통해 통신하는 방법은 나중에 따로 블로그를 작성할 예정입니다.

먼저 루트 페이지를 테스트했습니다.
테스트는 분당 1000개의 호출, 즉 10개의 프로세스에서 100개의 스레드 호출을 요청하도록 설정되었습니다.


총생산


평균 테스트 시간(ms)

여기서 TPS는 시스템이 초당 처리할 수 있는 트랜잭션 수이고 Mean Test Time은 요청을 보내고 응답을 받을 때까지의 평균 시간입니다.

TPS는 191.5, 피크 TPS는 383, 평균 테스트 시간은 3,715밀리초였습니다.

유사한 설정에서 여러 번 테스트를 실행한 후 결론 도출

  1. TPS와 Peak TPS의 차이가 크지 않기 때문에 일관된 성능을 보여주고 있는 것 같습니다.
  2. 평균 테스트 시간은 3,715밀리초로 비교적 높은 편이다.
  3. 테스트 과정에서 몇 가지 오류가 발생했습니다.
    일부 작업에서 오류가 발생할 수 있습니다.

그러나 보다 자세한 분석을 위해서는 추가 측정이 필요합니다.

다음으로 로그인 테스트를 실행했습니다.
스크립트는 http 요청 본문에 데이터베이스에 있는 사용자 이름과 암호를 포함하여 post 방식으로 작성됩니다.

이 테스트는 현재 사용자 세션을 redis에 저장하는 효과를 측정하려고 시도합니다.
redis가 적용될 때와 적용되지 않을 때 테스트하는 두 가지 방법이 있습니다.
이전 테스트와 달리 10분 이내에 2000개의 통화를 설정했습니다.

  • redis 없이 테스트


총생산


평균 테스트 시간(ms)

  • redis로 테스트


총생산

평균 테스트 시간(ms)

숫자의 차이는 작지만 가장 큰 차이는 피크 TPS그리고 평균 테스트 시간 예. Redis를 사용한 테스트는 최고 TPS가 더 높고 평균 테스트 시간이 더 빠릅니다.

Spring Security에서 제공하는 세션 관리 방법은 기본적으로 HTTP 세션을 사용하여 서버의 메모리에 세션 정보를 저장합니다.
이 방법은 Redis의 작동 방식과 유사하지만 Redis와는 다른 특성을 가지고 있습니다.

첫째, HTTP 세션은 메모리에 저장되기 때문에 서버가 다시 시작되거나 프로세스가 종료되면 모든 세션 정보가 손실됩니다.
따라서 서버의 신뢰도가 낮으면 세션 정보가 유실될 가능성이 있다.

반면 Redis는 디스크뿐만 아니라 메모리에도 데이터를 저장하므로 서버 안정성이 향상됩니다.
또한 Redis는 세션 정보를 분산하여 저장할 수 있으므로 여러 서버에서 세션 정보를 공유할 수 있습니다.
이러한 특성 때문에 Redis는 대규모 분산 시스템에서 세션 관리에 적합한 솔루션이라고 볼 수 있습니다.

따라서 사용자 세션을 메모리에 저장하는 것은 Spring Security에서 Redis를 사용하는 것과 동작 방식이 유사하지만 분산 환경에서 서버 안정성과 확장성에 차이가 있습니다.

성능 테스트의 경우 Spring Security가 세션을 메모리에 저장하는지 Redis에 저장하는지 여부에 따라 특정 상황에 따라 성능이 더 좋아집니다.

일반적으로 메모리에 세션 정보를 저장하는 메서드는 빠르게 액세스할 수 있기 때문에 높은 성능을 발휘할 수 있습니다.
그러나 Redis를 사용할 때 추가 네트워크 오버헤드로 인해 애플리케이션의 전체 응답 시간이 상당히 느려질 수 있습니다.

따라서 어떤 방법이 더 나은 성능을 제공하는지는 어플리케이션의 요구 사항과 환경에 따라 다르므로 각각의 경우에 적합한 방법을 선택해야 합니다.
높은 트래픽을 처리하는 대규모 시스템의 경우 세션 관리를 위해 Redis를 사용하는 것이 적절하다고 생각합니다.