상태 코드, 성능 문제로 읽는 304와 503

상태 코드는 성능 진단 자료입니다

상태 코드를 오류 표시로만 보면 진단 자료를 버리는 셈입니다. 코드 분포는 성능 문제의 성격을 알려 줍니다. 재검증 성공이 많다면 캐시가 작동하고 있다는 뜻입니다. 이 응답은 본문이 없어 전송량이 거의 들지 않으므로 많을수록 좋습니다. 반대로 서버 과부하를 알리는 코드가 보이면 용량이나 의존성 문제입니다. 리다이렉트가 많다면 불필요한 왕복이 생기고 있다는 신호입니다. 그래서 성능 점검의 첫 단계는 응답 코드 분포를 뽑는 일입니다. 분포를 보지 않고 특정 페이지만 측정하면 전체에 퍼진 문제를 놓칩니다.

코드별로 할 일이 정해져 있습니다

분포를 뽑았으면 코드별로 조치를 연결합니다. 재검증 성공이 적다면 캐시 헤더를 점검합니다. 리다이렉트가 많다면 어떤 입력이 왕복을 만드는지 찾아 한 번으로 줄입니다. 없는 자원을 가리키는 코드가 많다면 끊어진 링크나 삭제된 이미지를 찾습니다. 이 코드가 많으면 서버 계산이 낭비되고 사용자는 깨진 화면을 봅니다. 과부하를 알리는 코드가 보이면 그 시각의 요청 수와 응답 시간을 함께 봅니다. 요청 수가 평시 수준인데 과부하가 났다면 외부 의존성이나 데이터베이스 쪽 문제입니다. 이렇게 코드와 조치를 짝지어 두면 진단이 빨라집니다.

분포를 숫자로 집계합니다

학습용 가정으로 계산합니다. 가정값은 월 요청 500,000건이고 재검증 성공이 30퍼센트, 과부하 응답이 0.5퍼센트라고 두겠습니다. 재검증 성공은 150,000건이고 과부하는 2,500건입니다. 나머지 정상 응답을 347,500건으로 두면 세 항목의 합이 150,000 더하기 347,500 더하기 2,500으로 500,000건이 되어 전체와 일치합니다. 이 일치 확인이 중요합니다. 합이 맞지 않으면 집계에서 빠진 코드가 있다는 뜻입니다. 최종 판단은 과부하 2,500건이 언제 발생했는지 시각 분포를 보는 것입니다. 특정 시각에 몰려 있으면 용량 문제이고, 고르게 퍼져 있으면 특정 요청의 문제입니다.

코드가 정확하지 않은 경우가 있습니다

결론을 뒤집는 조건은 코드 사용의 정확성입니다. 오류가 났는데도 정상 코드로 응답하는 애플리케이션이 드물지 않습니다. 화면에는 오류 문구가 나오지만 상태 코드는 성공이어서 집계에 잡히지 않습니다. 그래서 분포가 깨끗해 보여도 사용자 불만이 있으면 애플리케이션의 코드 사용을 먼저 점검합니다. 두 번째 조건은 없는 경로 처리입니다. 브라우저에서 경로를 처리하는 방식의 사이트는 모든 경로를 정상 코드로 응답하도록 설정하는 경우가 있어, 진짜로 없는 경로도 성공으로 집계됩니다. 그래서 그런 사이트는 별도 지표로 끊어진 링크를 세어야 합니다.

성능 최적화 실행 전 점검표

• 응답 코드 분포를 먼저 뽑았다
• 코드별 조치를 짝지어 적었다
• 집계 합이 전체 요청 수와 일치하는지 확인했다
• 애플리케이션이 오류를 정상 코드로 응답하지 않는지 점검했다