[📈 성능 개선] IpRateLimitingFilter 최적화

[jbh010204]

🎯 테스트 시나리오 정의

어떤 기능에 대해 어떤 상황을 가정하여 성능 테스트를 진행할 것인지 구체적으로 작성합니다.

• 테스트 대상 API: [HTTP Method] /api/v1/...
• 핵심 로직: (예: 게시글 목록 조회, 복잡한 조인 쿼리 포함)
• 부하 테스트 도구: (예: nGrinder, JMeter, k6)
• 테스트 환경: (예: 로컬 MacBook Pro (M1, 16GB), DB는 Docker, 애플리케이션 메모리 1GB)

---

📊 1차 성능 측정 결과 (개선 전)

개선 작업을 진행하기 전의 성능 지표를 기록합니다. (Before)

지표 (Metric)	측정 값 (Value)	단위 (Unit)
VUser (가상 사용자 수)		명
TPS (초당 트랜잭션 수)		tps
평균 응답 시간 (Avg. Latency)		ms
최대 응답 시간 (Max. Latency)		ms
에러율 (Error Rate)		%

[nGrinder, JMeter 등 결과 그래프 스크린샷을 여기에 첨부해 주세요]

---

🧐 병목 지점 분석 및 가설

1차 측정 결과를 바탕으로 어떤 부분에서 병목이 발생하고 있는지 분석하고, 원인에 대한 가설을 세웁니다.

가설:
(예: N+1 쿼리 문제로 인해 DB 조회 시간이 과도하게 소요될 것으로 추정됨.)

근거:

• APM(Pinpoint, Sentry 등)에서 특정 메서드 지연 확인
• 느린 쿼리 로그(Slow Query Log)에서 해당 쿼리 발견
• 높은 CPU / Memory 사용량 확인 (구간: )
• 코드 리뷰 (비효율적인 로직, 불필요한 API 호출 등)
• 기타:

---

🛠️ 개선 전략 및 실행

위 가설을 바탕으로 어떤 방식으로 문제를 해결할 것인지 구체적인 전략을 작성하고 실행합니다.

전략:
(예: JPA의 Fetch Join을 사용하여 N+1 문제를 해결. 또는, 자주 변경되지 않는 데이터에 캐싱(Redis, Caffeine)을 적용.)

관련 PR:

• #(PR 번호)

---

📊 2차 성능 측정 결과 (개선 후)

개선 작업 후, 1차 측정과 동일한 조건으로 다시 성능을 측정하여 기록합니다. (After)

지표 (Metric)	측정 값 (Value)	단위 (Unit)
VUser (가상 사용자 수)		명
TPS (초당 트랜잭션 수)		tps
평균 응답 시간 (Avg. Latency)		ms
최대 응답 시간 (Max. Latency)		ms
에러율 (Error Rate)		%

[개선 후 결과 그래프 스크린샷을 여기에 첨부해 주세요]

---

✨ 최종 결론

개선 전/후 지표를 비교하여 개선 효과를 정량적으로 요약하고, 결론을 작성합니다.

개선 효과 요약:

• TPS: (개선 전 값) -> (개선 후 값) ( 약 O 배 증가 )
• 평균 응답 시간: (개선 전 값) -> (개선 후 값) ( 약 O % 감소 )

결론:
(예: Fetch Join 적용으로 N+1 문제를 해결하여 DB I/O를 크게 줄였고, 그 결과 TPS는 2.5배 증가, 평균 응답 시간은 60% 감소하는 효과를 확인했습니다.)

추가 논의 사항:
(예: 향후 트래픽 증가 시 스케일 아웃 전략 필요, 캐시 동기화 문제에 대한 추가 논의 필요 등)