Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
Tags
- 오버라이딩
- StringBuffer
- 다형성
- 무디스
- 잉여현금흐름
- 프로그래머스
- object
- 미국주식
- 객체지향
- javascript
- 금리인상
- FCF
- 금리인하
- 주린이
- 배당성장
- 자바
- XLF
- 현금흐름표
- 주식
- 백준
- etf
- 인플레이션
- 접근제어자
- 기업분석
- 알고리즘
- mco
- Java
- 제태크
- 그리디 알고리즘
- S&P500
Archives
- Today
- Total
오늘의하루
[SourceCode.io] 4차 성능 테스트 : 분석 및 해결책 본문
개선 사항
- 시간 복잡도 개선: O(N^2)의 시간 복잡도를 가진 메소드를 O(N)으로 개선했습니다. 이로써 데이터 처리 과정의 속도가 향상되었습니다.
- 압축 해제 라이브러리 사용: 기존에는 ZipInputStream을 사용했으나, Apache의 archivers를 사용하여 압축을 해제하는 방식으로 변경했습니다. 이는 성능과 안정성을 향상시켰습니다.
- 데코레이터 사용: 주석 제거 전 프로세스에서 ArchiveInputStream으로 Stream을 만들어서 주석 제거 메소드에서 Stream을 사용하여 파일 IO작업의 성능을 높였습니다. 이로써 파일 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
- 4차 테스트 : 2.3/sec
- Average 비교
- 1차 테스트 : 351,514ms
- 2차 테스트 : 60,821ms
- 3차 테스트 : 42,222ms
- 4차 테스트 : 40,259ms
결과 분석
3차 테스트에 비해 Throughput은 약 4.65%, Average는 약 9.52% 개선되었습니다.
2차 테스트에 비해 Throughput은 약 53.33%, Average는 약 33.84% 개선되었습니다.
1차 테스트에 비해 Throughput은 약 1252.94%, Average는 약 88.55% 개선되었습니다.
문제 파악 및 해결 방안
- 메모리 관리: 부하 테스트시 메모리는 비교적 안정적이지만 CPU와 디스크가 과부하 현상을 일으키고 있기 때문에 이를 해결하기 위해 공부할 계획입니다.
- 속도 개선: 현재로서는 속도를 개선하는 방법을 알지 못합니다. 따라서 모니터링 도구인 VisualVM을 활용하여 세부적인 내용을 확인하고 개선할 예정입니다.
- 로드 밸런싱 고려 : 아직 고려해볼 단계는 아닌거 같지만 로드 밸런싱을 통해 트랙픽 분산이 가능하기 때문에 100명이 동시에 접근하여도 3x명으로 나눠지기 때문에 성능 개선에는 도움이 될것이라고 예상됩니다. 하지만 로드 밸런싱을 고려 하기 전 정말 최대한의 효율을 낼 수 있도록 노력해야 할것 같습니다.
배운점
- 병렬 처리는 만능이 아니다: 병렬 처리를 통해 항상 성능이 향상되지 않는다는 점을 몸소 깨달았습니다. 병렬 처리와 순차적 작업을 직접 비교해본 결과, 작업의 특성과 환경을 고려하지 않고 단순히 병렬 처리를 적용할 경우, 예상보다 성능이 나빠질 수 있다는 것을 경험적으로 확인했습니다. 병렬 처리로 인한 추가적인 오버헤드와 자원 경합 등의 문제가 발생할 수 있으며, 이러한 문제를 해결하기 위해서는 신중한 분석과 효율적인 알고리즘 선택이 필요합니다. 이러한 경험을 통해 병렬 처리가 항상 최적의 선택이 아니라는 점을 명심하고, 작업에 적합한 처리 방식을 선택하는 것이 중요하다는 것을 깨달았습니다.
'Spring > SourceCode.io 프로젝트' 카테고리의 다른 글
[SourceCode.io] 5차 성능 테스트 : 분석 및 해결책 (0) | 2024.04.14 |
---|---|
Load Balancing을 통한 성능 최적화와 AWS의 활용 (0) | 2024.04.08 |
[SourceCode.io] 3차 성능 테스트 : 분석 및 해결책 (0) | 2024.04.02 |
[SourceCode.io] 2차 성능 테스트 : 분석 및 해결책 (0) | 2024.03.29 |
[SourceCode.io] 1차 성능 테스트 : 분석 및 해결책 (0) | 2024.03.28 |
Comments