Final Project - Random Navi - 트러블슈팅 - Jmeter
프로젝트의 1차 성능 테스트를 하기 위해 Jmeter를 사용하기로 했다.
Jmeter는 Apache 에서 개발된 오픈소스 테스트 도구로
주로 웹 응용프로그램의 성능을 측정하고 평가하기 위한 기능을 제공한다.
Jmeter를 사용하는 이유는 다음과 같다
Jmeter의 장점
1. 다양한 프로토콜 지원
- HTTP, HTTPS, JDBC, TCP등 다양한 프로토콜을 지원하고 데이터베이스, 메시징 시스텀, 이메일 서버등을 대상으로 테스트 할 수 있다.
2. 부하 및 성능 테스트
- 여러 동시 사용자가 웹 서버 또는 웹 서비스에 요청을 보내고 시스템이 어떻게 대응하는지 평가 할 수 있다.
3. 다양한 테스트 시나리오
- 스레드 그룹을 통해서 여러가지 시나리오를 구성 할 수 있다.
사용자 수, 루프 횟수, 램프업 시간, 시나리오의 변형등을 조절할 수 있다.
4. 분산 테스트
- 여러 컴퓨터에서 동시에 테스트를 실행하고 결과를 수집하는 분산 테스팅이 가능하다.
5. 테스트 스크립트
- 테스트 계획은 XML 형식의 스크립트로 저장하고 다시 불러오는 기능을 제공한다. 그래서 테스트 시나리오를 공유하거나 재사용 할 수 있게 된다.
6. 리포팅 및 그래프
- 테스트 결과에 대해 다양한 리포트와 그래프를 생성한다. 이를 통해서 응답 시간, 에러율, 트랜잭션 수 등을 시각적으로 분석 할 수 있게 된다.
7. 그래픽 사용자 인터페이스(GUI)
- 사용자 편의성을 위해 GUI 를 제공한다. 이로 인해 테스트 계획을 시각적으로 구성하고 실행 할 수 있다.
8. 확장성
- 다양한 확장기능과 플러그인을 제공해서 사용자의 요구에 따라 확장이 가능하다.
물론 장점만 있지 않고 단점도 존재 한다.
Jmeter의 단점
1. 학습 곡선
- JMeter는 강력하고 다양한 기능을 제공하지만 초기 학습 곡선이 높을 수 있다. 복잡한 시나리오를 구축하고 구성하는 데 시간이 걸릴 수 있고 처음 사용하는 사용자에게는 어려울 수 있으며, 초보자에게는 진입 장벽이 높을 수 있다.
2. 리소스 사용량
- JMeter는 메모리와 CPU 리소스를 상당히 사용한다. 따라서 대규모 테스트를 수행할 때 충분한 리소스가 필요하고 대용량 테스트를 실행할 때 서버 리소스가 부족할 수 있어 추가적인 하드웨어를 필요로 할 수 있다.
3. GUI 사용의 한계
- JMeter의 그래픽 사용자 인터페이스(GUI)는 편리하긴 하지만 대규모 테스트 계획 및 실행 시에는 한계가 있다. GUI를 사용하면 성능이 저하될 수 있으며 대규모 테스트를 위해 스크립팅 방식으로 사용하는 것이 권장된다.
4. 복잡한 시나리오 처리
- JMeter는 복잡한 시나리오 처리에 제한이 있을 수 있다. 특히 동적 데이터 생성 및 처리, 병렬 실행, 테스트 데이터의 동적 변경과 같은 복잡한 요구 사항을 다루기 어려울 수 있다.
5. 분산 테스팅 설정의 복잡성
- 분산 테스트 환경을 구성하고 관리하는 것은 어려울 수 있다. 여러 대의 컴퓨터에서 테스트를 실행하고 결과를 수집하는데 필요한 설정 및 관리 작업이 필요하다.
6. 문서화의 한계
- JMeter의 공식 문서는 간단한 사용법을 제공할 뿐, 고급 기능 및 복잡한 시나리오 설정에 대한 자세한 정보가 부족할 수 있습니다. 사용자는 사용자 커뮤니티와 온라인 자료를 활용하여 추가 정보를 얻어야 할 수 있다.
7. 보안 취약점
- JMeter는 주로 부하 및 성능 테스트를 위해 설계되었으며, 보안 테스트에 특화되지 않았다. 따라서 보안 취약점 스캔 및 페네트레이션 테스트를 위해 다른 전문 도구를 사용해야 할 수 있다.
8. 브라우저 동작 시뮬레이션 한계
- JMeter는 웹 브라우저의 동작을 완벽하게 시뮬레이트하지 못할 수 있으며, JavaScript 실행, 브라우저 캐싱, 쿠키 처리 등의 측면에서 한계가 있을 수 있다.
9. 확장성의 제한
- JMeter는 기본적으로 웹 응용 프로그램 및 웹 서비스를 대상으로 하는데, 다른 유형의 응용 프로그램이나 프로토콜에 대한 확장성이 제한될 수 있다.
10. 제한적인 테스트 데이터 관리
- 테스트 데이터의 생성, 관리 및 동적 변경을 위한 기능이 제한적일 수 있으며, 복잡한 테스트 데이터 요구 사항을 다루기 어려울 수 있다.
Jmeter의 장점과 단점을 파악하고 난 후
Jmeter를 설치하고 실행 시켜 보았다.
설치와 실행은 조원이 블로그에 잘 정리 해 놔서 그걸 보고 참고했다
오늘 테스트 할 코드는 경로를 저장하는 History Controller중에 일부분이다.
@PostMapping("/routes")
@Operation(summary = "경로 저장", description = "경로를 저장합니다.")
public ResponseEntity<String> saveRoutes(@RequestBody HistoryRequestDto requestDto,
@AuthenticationPrincipal UserDetailsImpl userDetails) {
historyService.saveHistory(requestDto.getRequestData(),
requestDto.getOriginAddress(), requestDto.getDestinationAddress(), requestDto.getMapType(),
userDetails.getUser());
return ResponseEntity.ok("Data received successfully"); // 성공 응답
}
코드를 확인해서 parameter를 확인하고
아래와 같이 구성했다.
Context-type은 application/json으로 설정했다.
마지막으로 path설정까지 하고 Name과 Value 값도 넣어주고
맨 위에 있는 실행 버튼을 눌렀으나 결과가 안나왔다.
name과 value값도 잘 지정했는데 결과가 안나왔다.
1~2일 동안 뭐가 문제일까 하고 계속 구글링을 했고 힌트를 조금씩 얻어가면
계속 시도해 보았지만
결과는 위의 사진과 같았다
마지막으로 GPT에 질문을 남겼는데 다음과 같은 답변이 나왔다.
GPT 답변
`@AuthenticationPrincipal`을 사용하여 UserDetails를 직접 주입받는 경우, JMeter와 같은 성능 테스트 도구를 사용할 때 UserDetails를 포함한 사용자 인증 및 세션 관리를 다루기 어려울 수 있습니다. UserDetails에 대한 의존성 때문에 단순한 HTTP 요청 테스트만으로는 성능 측정이 어려울 수 있습니다.
성능 테스트 시에 UserDetails와 같은 사용자 인증 정보를 처리하지 않고 성능을 측정하려면 다음과 같은 방법 중 하나를 고려할 수 있습니다:
1. **Spring Security 비활성화**: 성능 테스트를 위해 Spring Security를 비활성화하고 UserDetails에 대한 의존성을 제거하는 방법입니다. 이렇게 하면 사용자 인증이 무시되며 UserDetails를 주입하지 않아도 됩니다. 이 방법은 보안을 제거하므로 주의해서 사용해야 합니다.
2. **테스트 전용 사용자 생성**: UserDetails에 대한 의존성을 제거하고, 테스트용 사용자를 생성하여 UserDetails를 사용하지 않는 대신 테스트 데이터로 사용합니다. 이 방법은 실제 사용자 데이터와 격리되어 있으며, 테스트를 더 정확하게 수행할 수 있습니다.
3. **RESTful API 테스트**: Spring Boot 애플리케이션에서 UserDetails를 필요로하지 않는 RESTful API 엔드포인트를 추가하고, 이 엔드포인트를 테스트합니다. 이 방법은 사용자 인증을 무시하고 API의 성능을 측정하는 데 유용합니다.
4. **인증 토큰 사용**: Spring Security를 사용하여 사용자를 인증하고 토큰을 발급하고, 이 토큰을 사용하여 요청을 보내는 방법을 고려할 수 있습니다. 이 방법은 UserDetails를 필요로하지 않고, 토큰을 사용하여 요청을 인증하며, JMeter와 같은 도구에서 테스트하기 쉽습니다.
상황 및 요구사항에 따라 적절한 방법을 선택할 수 있습니다. UserDetails를 포함한 사용자 인증 관련 정보가 필요 없다면, 1번 또는 3번과 같은 방법을 고려하여 성능 테스트를 수행할 수 있습니다.
생각지도 못한 문제점이 발생해서 코드를 수정하고 나서 Jmeter를 측정해야 할 것 같다.