엉뚱한 곳을 고치던 성능 조사

응답이 느리다는 이야기를 듣고 코드를 열었더니 반복문 안에서 조회하는 자리가 눈에 띄었다. 며칠 걸려 그것을 합쳤는데 체감이 그대로였다.

Open Table of contents

추측으로 고친 자리

코드를 읽고 개선할 곳이 보이면 그것이 원인이라고 생각하기 쉽다. 그 자리가 실제로 느린지는 확인하지 않은 채였다.

고친 결과가 안 보이는데 왜 안 보이는지도 알 수 없었다. 추측으로 고치면 안 나아졌을 때 다음에 무엇을 볼지도 안 정해진다.

요청이 들어와서 나갈 때까지 각 구간에 시각을 찍었다. 인증과 데이터 조회와 외부 호출과 응답 생성이 각각 얼마를 쓰는지가 나왔다.

전체의 대부분이 외부 호출에서 쓰이고 있었고 내가 고친 데이터 조회는 십 분의 일 남짓이었다. 그것을 절반으로 줄여도 전체는 몇 퍼센트만 나아지므로 체감이 안 바뀐 것이 당연했다.

외부 호출을 들여다보니 한 요청에 세 번을 순서대로 부르고 있었다. 서로 의존하지 않는 것을 확인하고 동시에 부르게 하니 그 구간이 삼분의 일로 줄었다.

목록 화면에서 항목마다 같은 설정을 반복 조회하는 것도 있어서 한 번 받아 재사용하게 했다. 코드 안을 다듬는 것보다 호출 구조를 바꾸는 쪽이 훨씬 크게 움직였다.

처음에는 평균 응답 시간을 봤고 나쁘지 않은 값이었다. 그런데 불만이 계속 나와서 분포를 봤다.

대부분은 빠른데 소수가 몇 초씩 걸리고 있었고 불만은 그 소수에서 나온 것이었다. 평균을 낮추는 것과 오래 걸리는 쪽을 없애는 것은 다른 목표라서 이후로는 상위 구간의 시간을 봤다.

오래 걸리는 요청만 따로 모으니 데이터가 많은 계정과 배치가 겹치는 시간대와 외부가 느린 순간 셋으로 갈렸다. 앞의 둘은 우리가 손댈 수 있고 마지막은 우리 문제가 아니었다.

그래서 외부 호출에 시간 제한을 두고 안 오면 그 항목만 비운 채로 나머지를 보여 주게 했다. 전에는 하나가 느리면 전체가 느렸는데 이제는 하나가 느리면 그 자리만 빈다.