load test와 CPU rate

White Piano·2023년 8월 16일
0

뭔가 잘못됐다

docker로 배포 환경과 비슷한 자원을 주고 load test를 시행했다. 결과는 불만족스러웠다. 기본적으로 latency가 최대 2,324ms까지도 올라간 데다가 테스트가 진행되는 10분간 latency 증가가 멈추지 않았다. 해결해야만 했다.

최근 3-layered architecture를 접해서 당장 성능을 개선하기에 앞서 중구난방인 코드를 다듬기로 했다. 그 결과물이 너무 만족스러웠고 구조 개편이 성능 향상으로 이어지진 않았을까 궁금했다.

성능이 말도 안 되게 향상됐다! 여전히 latency가 끝을 모르고 치솟고 있지만 수치는 만족스러웠다. 문제는 코드 구조를 개편하면서 정확히 어떤 변경이 성능 향상으로 이어졌는지 알기 어렵단 것이었다. 아쉬움을 안고 하루를 마무리했다.

하지만 잠에서 깨어난 후, 전날 마셨던 다디단 음료가 사실은 해골물이었단 사실을 깨달았다. 난 수정한 코드를 docker image로 빌드 한 적이 없었고 위 테스트 결과는 동일한 프로그램에 대해 수행됐다. 충격에서 벗어나자 당황스러웠다. 같은 프로그램의 성능이 너무 심하게 차이가 났다. 왜일까?

동일한 프로그램에 대한 동일한 성능테스트가 일관되지 않다면 테스트 결과는 아무짝에도 쓸모가 없다. 변인을 파악하고 안정적인 테스트 환경을 만들어야만 한다. 하지만 아무리 생각해도 이유를 가늠할 수 없었다. docker network를 bridge가 아니라 host로 설정해서일까? 하지만 성능 차이가 network에서 비롯되었다고는 생각하기엔 무리가 있었다.

절전모드

내 상황을 들은 친구가 테스트 환경이 노트북이었냐고 물었다. 나는 맞다고 대답했고, 그렇다면 CPU clock이 영향을 준것일거라고 얘기했다. 난 아니라고 답했다. 왜냐면 두 테스트 모두 CPU rate이 100%로 동일했기 때문이다. 두 테스트에서 사용된 CPU가 같으니 clock이고 뭐고 알게 뭐란 말인가? 그런데 친구는 아니라고, 분명 CPU clock이 원인일 거라며 배터리 부족으로 인한 절전모드를 의심했다. 생각해 보니 좋은 지표를 냈던 테스트를 진행할때는 노트북에 충전기를 연결해 둔 상태였다. 정말 clock이 원인일까? 이쯤 되니 궁금해졌다. CPU rate이 100%라는 건 무슨 의미인 걸까?

CPU Clock, CPU Usage

CPU Clock

단위는 GHz로 CPU가 초당 실행하는 cycle의 수를 말한다. 즉, Clock rate가 높은 CPU가 낮은 CPU보다 동일 시간에 더 많은 Inst를 수행한다.

(Clock rate이 높다고 무조건 성능이 더 좋은 것은 아니다. CPU Architecture에 따라 Inst 당 필요한 cycle이 더 적다면 Clock rate이 낮아도 더 좋은 성능을 낼 수 있다)

CPU Usage

단위시간 동안 CPU가 사용된 비율이다. 즉, CPU rate이 100%라는 건 측정시간 동안 CPU가 쉬지 않고 일했다는 의미다.

결론

CPU Rate이 100%라고 해서 동일한 CPU 자원을 사용한게 아니란 사실을 알았다. 발열 등의 상황으로 CPU에 제한이 걸리는것까지 제어하기는 힘들겠지만, 최소한 충전기를 연결하는 등 전원 설정을 동일하게 유지하고 테스트를 진행해야겠다.

처음에는 CPU rate을 100% 미만으로 유지해야만 하는게 아닐까 생각했지만 Server의 CPU rate이 100%인건 당연한게 아닌가 싶다. (물론 높아서 좋을일은 없겠지만) 그렇다면 왜 latency가 계속 증가하는 걸까? 아무래도 Little's law를 좀 더 공부하면서 load test duration을 늘려서 임계치를 찾아봐야겠다.

(추가) 노트북 전원 모드에 따른 성능 비교

< 전원모드 "균형" >

< 전원모드 "성능" >

1개의 댓글

comment-user-thumbnail
2023년 8월 17일

이렇게 유용한 정보를 공유해주셔서 감사합니다.

답글 달기