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 | 31 |
Tags
- 디버깅
- 카카오
- 구현
- AWS
- spring event
- 크롤링
- next-stock
- 추천 검색 기능
- 완전탐색
- 결제서비스
- 이분탐색
- 몽고 인덱스
- dau 3만명
- BFS
- 알람시스템
- JPA
- 쿠키
- 누적합
- 관측가능성
- piplining
- 프로그래머스
- gRPC
- 백준
- langgraph
- 아키텍쳐 개선
- 베타적락
- docker
- ai agent
- 셀러리
- ipo 매매자동화
Archives
- Today
- Total
목록2024/07/24 (1)
코딩관계론

서론기존의 타임딜 서비스를 구현하고 나서, nGrinder를 이용해 부하테스트를 진행했습니다. 900명의 유저가 동시에 접근해서 쿠폰 지급을 요청할 때, TPS가 190, 평균 응답시간은 2.3초가 나왔습니다. 따라서 부하가 많이 나오는 지점을 파악하여 성능을 개선 할 필요가 생겼습니다. 병목지점은 DB의 비관적 락부분과 실제 HDD까지 쓰기 작업이 완료되고 나서야 사용자에게 응답을 보내는 구조가 문제라고 생각했습니다. 따라서 이러한 문제점을 해결하기 위해 위해 In memory database를 도입하게 됐고, 궁극적으로 성능이 어떻게 개선됐는지 말씀드리겠습니다. In-memory-db를 도입했는가?속도적 측면아래 그림을 보면 속도적 측면이 있다. Redis에 접근해서 데이터를 읽을 때는 100ns +..
TroubleShooting
2024. 7. 24. 17:02