문제: 조회 성능이 매우 매우 느리다.
초기 거래소 조회 속도: 36.8초
1차 개선 후: 24.17초
개선내용:
1. tradeCount 집계테이블 생성
2. tradeCount테이블의 count에 인덱스 생성(asc)
3. 마켓status와 createdAt 복합인덱스 생성
4. trade에 createdAt 인덱스 생성(desc)
문제점: 인덱스가 너무 많고, trade에 인덱스가 걸려있어 삽입 시 오버헤드 우려됨. trade는 삽입이 활발히 일어나는 항목이므로 해당 부분에 대한 개선 필요했음
커서기반 페이지네이션 적용 후: 3.6초
개선내용:
1. 커서 기반 페이지네이션 적용
2. 정렬 전략 별로 다른 cursor 사용, tie-breaker로 itemId 사용
3. 조건에 따른 조회와 검색이 많이 일어나는 항목이므로, (status,createdAt, itemId, amount, price) 복합 인덱스 생성. 이전처럼 인덱스를 많이 사용하기보다 하나의 인덱스로 성능을 개선함.
문제점: market 삽입 시 오버헤드를 고려할 필요가 있으나, trade보단 빈도가 덜할 것이기에 상대적으로 괜찮다고 판단함.
풀텍스트 인덱스 적용 후: 39ms
개선내용: CustomFunctionContributor 이용하여 풀텍스트 인덱스 적용
caching
튜닝을 마치지 못한 느린 쿼리(거래소 인기내역): 26.7초
문제점: cursor와 tie-breaker를 넣어주면 그나마 속도가 빠르지만, 인기 내역 첫 로드 시 조회속도가 매우 느림. 원인 찾지 못하였고, 이후 생각날 때 마다 개선 예정.
해결(임시방편): redis 캐싱을 이용하여 성능 향상. 어차피 인기 내역은 변동성이 적기 때문에 TTL을 꽤 길게 가져감.
DB 부하 감소: 느린 쿼리로 인한 DB 트래픽 줄여줌
'팀 프로젝트 > 플러스 프로젝트' 카테고리의 다른 글
조회성능 개선 마무리(저장용 글) (0) | 2025.02.06 |
---|---|
성능 개선 4편 & 트러블슈팅: 커서 기반 페이지네이션 + 전략 패턴 (0) | 2025.02.05 |
성능 개선 3편: Index 적용하고 비교분석하기 (0) | 2025.02.04 |