[ 230820 ] 36주차 회고

일주일 간 진행한 내용

 

1. 성능 테스트 기준 선정
2. 서버에서 성능 테스트 

 

 

---

성능 테스트 기준 선정

 

[진행]

기능 구현이 끝나고 나서 성능 테스트를 하기 위해서 기준을 선정해야 했다. 우리가 넣어놓은 데이터의 숫자를 기준으로 하기로 했다. 일반적인 트래픽, 인기 있고 자주 사용되는 기능의 트래픽을 분리하기로 했다. 일반적인 트래픽은 유저 10만 건을 기준으로 1분에 활성 유저를 2~5%(2,000~5,000명) 정도로 잡았다. 인기 있고 자주 사용되는 기능의 트래픽의 경우 일반적인 트래픽 10배(20,000~50,000명)으로 했다. 급격하게 몰릴 경우 배수로 급증하는 것을 고려해봐야 할 것 같아서다. 우리가 이뤄보고 싶은 목표가 담겨 있기도 했다.

 

[생각]

성능 테스트 기준을 정하는 것은 쉽지 않았다. 적절한 근거를 설정하는 것이 어려웠기 때문이다. 그래서 우리가 바라는 희망사항이 많이 들어간 것 같다. 이러한 기준이 나름 맘이 들었다. 퍼센트로 적절한 수치를 정할 수 있었을 뿐만 아니라, 지금이 아니면 언제 또 이러한 목표를 설정하고 그만큼의 성능을 내기 위해서 시도해 볼 수 있겠는가? 싶어서다.  

 

 

 

---

서버에서 성능 테스트

 

[진행]

로컬에서 성능 테스트를 시도해보았다. 서버에서 하기 전에 Jmeter에 익숙해지기 위해서였다. 로컬 성능 테스트가 익숙해지고 나서 서버에서 성능 테스트를 했다. 내가 맡은 부분은 업데이트와 삭제 기능이었다. 우리가 설정해 놓은 기준으로 1분간 3,000건, 5,000건, 10,000건을 테스트해 봤다. 3,000건, 5,000건의 경우 TPS도 적절하게 나왔고 오류율이 거의 없었다. 하지만 10,000건의 경우 TPS도 낮게 나왔으며 오류율이 엄청나게 발생했다. 하지만 업데이트와 삭제 기능은 일반적인 트래픽에서만 커버를 쳐도 되는 기능이라고 판단이 되기에 성능 개선을 따로 하지 않기로 했다.

 

[생각]

성능 테스트를 직접 기획하고 해보는해 보는 것이 처음이었다. Jmeter를 다뤄보는 것도 어려웠다. 그래도 재미가 있었다. 처음 해보는 것이기도 했고 실질적으로 성능이 지표가 바로 보였기 때문이다. 상황에 따라서 성능 개선의 여지를 가지고 있었기 때문에 그런 것을 해볼 수 있다는 기대감도 있었다. 하지만 일반적인 트래픽도 감당이 가능하다고 판단이 들어서 성능 개선을 안 해도 되어서 아쉬운 감이 있었지만, 이러한 경험이 나의 자산이 될 것이다. 다음에는 조금 더 익숙해서 잘하겠지.