[SourceCode.io] 3차 성능 테스트 : 분석 및 해결책

개선 사항

1. 프로세스 단계 간소화: 불필요한 프로세스 단계를 제거하고, 필요한 작업을 더 효율적으로 처리하기 위해 프로세스를 재구성했습니다. 이로써 프로세스의 실행 속도를 향상시켰습니다.
2. String 객체 생성 최소화: 불필요한 String 객체 생성을 제거하고, 메모리 사용을 최적화하기 위해 InputStream을 활용하여 데이터를 처리하도록 수정했습니다.
3. 버퍼 크기 증가: 프로세스의 효율성을 높이기 위해 버퍼 크기를 4096byte로 증가시켰습니다. 이는 프로세스의 데이터 처리량을 늘려서 성능을 향상시켰습니다.
4. 불필요한 IO 작업 제거: 불필요한 IO 작업을 최소화하여 메모리 사용을 줄였습니다. 이는 프로세스의 부하를 감소시켜서 전반적인 성능을 향상시켰습니다.

환경 설정

• Apache JMeter version : 5.6.3
• Spring boot version : 3.2.2
• Java version : 17

시나리오

JMeter를 사용하여 100명의 가상 사용자가 동시에 100MB 크기의 zip 파일을 서버에 첨부하고, 해당 파일을 분석한 후 결과를 반환하도록 시나리오를 작성했습니다.

테스트 결과

부하 테스트를 수행한 결과, 사용자의 요청 후 응답까지의 평균 속도와 서버가 처리할 수 있는 양에 집중해야 한다는 것을 확인했습니다.

• Throughput 비교
  • 1차 테스트 : 10.2/min
  • 2차 테스트 : 1.5/sec
  • 3차 테스트 : 2.1/sec
• Average 비교
  • 1차 테스트 : 351,514ms
  • 2차 테스트 : 60,821ms
  • 3차 테스트 : 42,222ms

답답한 마음에 Thread 수를 10 ~ 50 까지 점차 증가 시키며 했던 테스트 결과

테스트 환경이 다르기 때문에 테스트 결과를 믿을 수 는 없다.

• Thread 10, Ramp-up period 1, roop 1 
  
  • Thoughput : 1.8/sec | Average : 3,969
• Thread 20, Ramp-up period 1, roop 1 
  • Thoughput : 2.5/sec | Average : 6,618
• Thread 30, Ramp-up period 1, roop 1 
  • Thoughput : 2.6/sec | Average : 10,107
• Thread 40, Ramp-up period 1, roop 1 
  • Thoughput : 2.4/sec | Average : 14,628
• Thread 50, Ramp-up period 1, roop 1 
  • Thoughput : 2.3/sec | Average : 20,222

결과 분석

2차 테스트에 비해 Throughput은 약 40%, Average는 약 30.5% 개선되었습니다.

1차 테스트에 비해서는 Throughput은 약 1135%, Average는 약 87.97% 개선되었습니다.

문제 파악 및 해결 방안

• 프로세스 세분화: 불필요한 부분을 제거하고 효율적으로 재구성하여 더 빠른 실행을 위해 노력할 것입니다.
• 프로파일링 도구 활용: 병목 현상을 파악하고 트래픽 흐름을 조사하여 성능을 개선하는 데 도움이 되는 프로파일링 도구를 활용할 계획입니다.
• 메모리 관리: 메모리 누수를 방지하고 오버헤드를 최소화하기 위해 지속적인 메모리 관리를 진행할 것입니다.

사용하게 될 프로파일링 도구

1. Spring Actuator
   • 운영 환경에서 모니터링 및 관리를 지원하는 엔드포인트를 제공하여 수집된 정보를 모니터링 시스템으로 전송하거나 직접 모니터링하는 등 다양한 운영 및 모니터링 시나리오에서 사용할 수 있습니다.
   • Actuator는 중요한 정보들이 많이 담겨 있기 때문에 사용할때는 보안을 철저히 하여 진행하여야 합니다.
2. Prometheus
   • 메트릭 및 로그 데이터를 수집하고 저장한 후 이를 검색하고 시각화하여 인프라스트럭처와 애플리케이션의 성능을 모니터링하는 시스템입니다.
3. Grafana
   • Prometheus와 통합하여 시각화 대시보드를 제공하여 시스템의 상태를 실시간으로 모니터링하고 문제를 진단할 수 있는 도구입니다.

배운점

1. 람다식과 외부 변수 활용: 람다식 내에서 배열을 사용하여 외부 변수를 활용할 수 있다는 것을 배웠습니다. 배열 변수는 한 번 생성되면 다른 배열을 참조할 수 없으므로 사실상 final이라고 간주됩니다. 그러므로 람다식 내부에서 배열의 요소를 참조하거나 변경하는 것은 가능합니다.
2. CPU 부하와 디스크 사용량 관계: CPU가 100%가 되면 갑자기 디스크 사용량이 빠르게 상승하는 것을 보고 찾아보본 결과 CPU 과부하가 발생하면 시스템의 성능이 저하될 수 있으며, 이로 인해 운영 체제가 스왑 파일을 통해 가상 메모리를 디스크로 옮기는 스왑 작업이 발생할 수 있습니다. 이는 메모리 부족 상황에서 메모리를 효율적으로 관리하기 위한 운영 체제의 메커니즘입니다. 따라서 CPU 과부하로 인해 디스크 사용량이 증가하는 상황을 이해할 수 있었습니다.
3. 지속적인 성능 개선의 중요성: 테스트 결과를 통해 시스템의 성능을 개선하는 과정이 중요함을 깨닫게 되었습니다. 지속적인 성능 모니터링과 개선은 사용자 경험을 향상시키고 시스템의 안정성을 유지하는 데 필수적입니다. 이를 통해 개발 과정에서 성능에 대한 고려가 필요함을 깨달았으며, 이를 통해 사용자와 시스템 모두에게 이점을 제공할 수 있을 것이라는 확신을 갖게 되었습니다.