일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
31 |
- DDL
- 생성자 주입
- stream
- jpa
- 필드 주입
- lambda
- docker
- 인덱스
- Spring
- KEVISS
- Test
- 조합
- AOP
- StringBuilder
- select_type
- 테스트 코드
- static
- 열 속성
- equals
- VUE
- cache
- MSA
- jwt
- DI
- redis
- SQL
- hashcode
- java
- Exception
- 재정의
- Today
- Total
백엔드 개발자 블로그
K6 본문
파레토 - 중요한거 먼저해라
주석 공부법 - 어떤 역할하는지 작성해봐라
자료
https://jscode.notion.site/14211062ff0780c2a77ee2f770da510a
처리량(Throughput) : 1초당 처리할 수 있는 트래픽 양, 단위 : TPS(1초당 처리한 트랜잭션의 수)
지연 시간(Lagtency) : 요청에 대한 응답 시간
툴 선정
메모리 적고 많은 요청 수 보낼 수 있음
AWS 설정 하여 간단한 API 개발
부하테스틀 셔틀 서버 세팅 (5665 open)
점진적으로 부하 늘리기 script
대시보드
public ip:5665 에서 실시간 데이터 확인 가
http_reqs이 수평선이 될때까지 부하테스트 실행
1. http_reqs = Throughput > 증가하지 않는 Throughput이 최대 Throughput, 이거 나올때까지만 해도 ㄱ
2. Requeest Duration = Latency > 점점 증가함, 지정한 시간보다 낮으면 합격
3. http request failed = 실패
병목 지점
전체 시스템에서 특정 서버 자원이 한계에 도달해 전체 성능이 저하되는 구간
부하 테스트 전체 흐름
1. 목표 Throughput, Latency 설정
2. 부하 테스트로 목표 도달했는지 파악
3. 도달 못하면 병목지점 파악
주의점
1. 적절한 부하 테스트 시간
2. 프로덕션 환경과 비슷한 데이터 셋팅
3. 프로덕션과 분리된 환경에서 테스트하기
4. 개인 컴퓨터에 ㄴㄴ 제한걸릴 때가 있다
1. 인프라 구성
Spring + RDS + ELB
2. 프로덕션 환경과 유사하게 부하 테스트
3. 병목지점 찾기
CPU
메모리
디스크
ec2 cpu
ec2 메모리
rds cpu
rds 메모
실시간 : top
가용성
이중
수평적 확장
수직적 확장
캐싱
EC2 병목 지점인 경우
1. 로직 개선
2. 정적 파일(S3, Cloudfront) 서버 분리
3. ELB를 활용해 수평적 확장
4. 수직적 확장
RDS 병목 지점인 경우
1. 쿼리 개선 (인덱스, SQL문 튜닝, 역정규화)
2. 수직적 확장
3. 읽기 전용 데이터베이스 도입
4. 캐시 서버 도입
1. 부하 테스트 목표 설정
2. 부하 테스트 진행
3. 병목 지점 파악 후 성능 개선
4. 개선한 시스템 부하 테스트 진
전문가가 알려주는 웹 퍼포먼스 튜닝
아마존 웹 서비스 부하 테스트 입
'트러블 슈팅' 카테고리의 다른 글
virtual thread (0) | 2025.05.02 |
---|---|
예외 처리 (0) | 2025.04.30 |
RDB 객체DB 객체 (0) | 2025.04.23 |
JPA의 ddl-auto 옵션 (0) | 2025.04.21 |
Spring Data JPA에서 새로운 Entity인지 판단하는 방법 (0) | 2025.04.21 |