인프런 커뮤니티 질문&답변

문영훈

작성한 질문수

6주 완성! 백엔드 이력서 차별화 전략 4가지 - 똑같은 이력서 속에서 돋보이는 법

2-9. 부하테스트 - k6 실습

k6 부하테스트 중인데 개선 전 성능이 너무 안나와서 고민

작성

수정됨

1. 현재 학습 진도

부하테스트

2. 어려움을 겪는 부분

부하 테스트의 코드를 통해 성능 개선 사례를 적으려고 합니다. 하지만 현재 평균 req_duration 즉 레이턴시가 너무 낮게 나옵니다. vus를 300으로 두었는데 아마 커넥션 풀이 모자라서 대기가 길어지는게 원인 같긴 합니다. 하지만 이걸 떠나서도 vus 300치고 너무 느리다고 판단되어서 이걸 개선했다고 포트폴리오에 쓰는게 의미가 있을지 걱정됩니다.

또한 커넥션 풀이 모자라다고 대기업 개발자들이 항상 aws의 사양을 up시켜 커넥션 풀만 늘려서 해결하는 해결 방식을 사용하지는 않을 것 같은데 보통 성능 최적화를 통해 커넥션풀 점유를 짧게 해서 최대한 커넥션풀 고갈을 방지하는 방식으로 해결하나요?

만약 그렇다면 성능 최적화 하는 방법에 부하를 분산하기 위한 kafka, redis, msa같은 기술들이 들어가는 건가요?

마지막으로 성능 최적화를 포트폴리오 이력에 쓸 때 적절한 vus수가 궁금합니다 예를들어 면접관이 봤을 때 300명이라면 너무 적다고 판단되지 않을까 걱정되어서 어느 정도의 대략적으로 vus가 적정 인원인지가 궁금합니다,

3. 시도해보신 내용

시도하진 않았지만 개선할 방법으로는 강의에서 제공해주신 mysql의 실행계획을 통해 index 추가와 커넥션풀 사이즈 늘리는 것 그리고 캐싱 도입을 생각하고 있긴합니다.

java spring mysql redis 이력서

답변 1

인프런 AI 인턴

안녕하세요, 인프런 AI 인턴입니다. 문영훈님.

k6 부하 테스트를 진행하시면서 성능 개선 사례를 이력서에 어떻게 적어야 할지 고민이 많으신 것 같습니다. 특히 현재 vus를 300으로 두었는데 성능이 기대에 미치지 못해 걱정이신 것 같네요.

성능 개선 방법 제안

커넥션 풀 사이즈 조정:
- 현재 커넥션 풀이 부족하여 대기 시간(레이턴시)이 증가하고 있는 것으로 보입니다. 커넥션 풀의 크기를 늘려서 동시 접속 요청을 처리할 수 있는 여력을 확보해보세요.
MySQL 인덱스 최적화:
- 인덱스를 통한 데이터베이스 최적화가 중요합니다. 실행 계획을 분석하여, 조회 쿼리가 효율적으로 처리될 수 있도록 인덱스를 구축하세요.
캐싱 도입:
- 자주 조회되는 데이터의 경우, 데이터베이스 직접 쿼리 대신 캐시를 사용하여 응답 시간을 줄일 수 있습니다. Redis와 같은 인메모리 데이터베이스를 고려해보세요.
부하 분산:
- 테스트가 특정 서버에 집중되고 있다면, 부하 분산을 위한 방법도 고려해보세요. 예를 들어, 더 많은 서버 인스턴스를 활용하여 부하를 분산할 수 있습니다.
성능 개선 후 측정:
- 성능 개선 전과 후의 지표를 명확히 기록해 두세요. 이는 이력서에 성능 개선 결과를 서술할 때 중요한 객관적 자료가 됩니다.

추가 자료

성능 테스트와 관련된 보다 구체적인 사례는 다음의 링크를 참조하시면 도움이 될 것입니다:

질문 제목: 백엔드 성능 테스트 최적화 방법
질문 제목: 성능 측정 및 지도 방법에 대해

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

문영훈

작성한 질문수

전체 Q&A

질문하기