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
- 누적합
- 몽고 인덱스
- BFS
- 검색어 추천
- 추천 검색 기능
- piplining
- 프로그래머스
- spring event
- 완전탐색
- docker
- ai agent
- 트랜잭샨
- 레디스 동시성
- 카카오
- 크롤링
- 백준
- 쿠키
- 구현
- JPA
- langgraph
- 아키텍쳐 개선
- jwt 표준
- ipo 매매자동화
- next-stock
- AWS
- 결제서비스
- 디버깅
- gRPC
- 셀러리
- 이분탐색
Archives
- Today
- Total
목록TPS (1)
코딩관계론

🔥 성능 개선 목표 설정서비스 이벤트가 열리면 100,000명의 사용자가 초당 5회의 요청을 수행하게 됩니다. 이 서비스는 10분간 유지되므로 초당 QPS는 8,400 TPS를 감당해야 합니다. (QPS와 TPS를 동일로 가정)🚩 초기 문제 발견DDD 기반으로 타임딜 서비스를 리팩토링한 뒤 성능 테스트를 진행했으나, TPS가 2라는 극단적으로 낮은 결과가 나왔습니다. 프로메테우스를 통해 분석한 결과, DB 커넥션 풀이 10개뿐이라 요청이 몰릴 경우 모든 커넥션이 활성화되고 대기 요청이 쌓이는 현상이 발생했습니다.하지만 Look Aside 캐싱 패턴을 사용했기 때문에, 최초 요청만 DB에 접근하고 이후 요청은 Redis에서 처리해야 했습니다. 원인을 분석한 결과, 캐시 접근 이전에 트랜잭션이 시작되면서..
개발
2024. 8. 22. 18:32