응답 시간

응답 시간은 요청을 보낸 쪽이 답을 받기까지 기다린 시간입니다. 사용자가 느리다고 느끼는 것이 이 값입니다. 서버가 일한 시간뿐 아니라 오가는 길과 줄 서서 기다린 시간까지 모두 들어갑니다. 그래서 같은 서버라도 붐빌 때 크게 늘어납니다.

쉽고 빠른 이해

무슨 일을 하는 값인가 — 요청 하나를 보내고 답이 돌아오기까지 걸린 시간을 잽니다. 버튼을 누르고 화면에 결과가 뜨기까지 2초가 걸렸다면 그 요청의 응답 시간은 2초입니다.

왜 재나 — 서버가 1초에 몇 건을 끝내는지만 보면 한 사람이 얼마나 기다렸는지는 안 보입니다. 기다리는 쪽의 불편은 건수가 아니라 시간에 붙어 있습니다.

어떻게 읽나

1. 요청마다 걸린 시간을 모읍니다
2. 평균 하나로 줄이지 않고 가장 느린 몇 건을 따로 봅니다
3. 성공한 요청과 실패한 요청을 갈라서 봅니다

주의할 점 — 어디서 재느냐에 따라 값이 달라집니다. 서버가 잰 값과 사용자 쪽에서 잰 값이 다르므로, 잰 곳을 같이 적지 않으면 두 숫자를 견줄 수 없습니다.

상세

이 절은 응답 시간이 어디서 시작해 어디서 끝나는 시간인지부터 봅니다. 그다음 그 시간이 어떤 구간으로 이루어지는지 봅니다. 마지막으로 왜 평균 하나로 읽으면 안 되는지를 요청 100건의 예로 따라갑니다.

식당에서 주문을 넣고 음식이 식탁에 오기까지 기다린 시간이 응답 시간입니다. 손님은 주방에서 요리한 시간만 따로 느끼지 않습니다. 주문이 밀려 차례를 기다린 시간도, 음식을 나르는 시간도 전부 기다림입니다.

시작과 끝

응답 시간은 클라이언트가 요청을 보낸 때에 시작해서 응답을 받은 때에 끝납니다. 클라이언트는 요청을 보내고 답을 기다리는 쪽입니다. 브라우저일 수도 있습니다. 다른 서버를 부르는 서버일 수도 있습니다.

끝을 잡는 방법은 두 가지입니다. 하나는 응답의 첫 바이트가 도착한 때입니다. 다른 하나는 마지막 바이트까지 다 받은 때입니다. 응답이 크면 두 값이 크게 벌어지므로 어느 쪽으로 쟀는지 같이 적습니다.

응답 시간을 이루는 구간

요청 하나는 답으로 돌아오기까지 몇 구간을 지납니다. 응답 시간은 이 구간들을 더한 값입니다. 어느 구간이 긴지에 따라 고칠 곳이 달라집니다.

flowchart TD
    A["클라이언트가 요청을 보낸다"] --> B["네트워크를 건너간다"]
    B --> C["서버 앞 줄에서 차례를 기다린다"]
    C --> D["서버가 처리한다"]
    D --> E["네트워크를 건너온다"]
    E --> F["클라이언트가 응답을 받는다"]

그림에서 서버가 일한 것은 「서버가 처리한다」 한 칸뿐입니다. 나머지는 요청이 길 위에 있었거나 줄에 서 있던 시간입니다.

네트워크 구간은 요청과 응답이 네트워크를 건너는 시간입니다. 서버와 클라이언트가 멀수록 길어집니다. 연결을 새로 맺어야 하면 더 길어집니다. 서버 코드를 고쳐도 이 구간은 줄지 않습니다.

대기 구간은 요청이 처리 차례를 기다린 시간입니다. 서버가 한꺼번에 붙잡을 수 있는 요청 수에는 한도가 있습니다. 한도를 넘어 들어온 요청은 큐에서 기다립니다. 큐는 도착한 일이 처리를 기다리며 줄 서는 곳입니다.

처리 구간은 서버가 요청을 받아 일한 시간입니다. 서버는 이 안에서도 데이터베이스나 다른 서비스를 부르고 답을 기다립니다. 그 기다림도 처리 구간에 들어갑니다.

응답 시간과 지연

지연은 어떤 일을 시작하고 결과를 받기까지 걸린 시간을 넓게 이르는 말입니다. 응답 시간과 뜻이 겹쳐서 두 낱말을 섞어 쓰는 사람이 많습니다.

둘을 가를 때는 보통 이렇게 나눕니다. 응답 시간은 클라이언트가 겪은 전체 시간입니다. 지연은 그 안의 한 구간, 예를 들어 네트워크를 건넌 시간이나 차례를 기다린 시간을 가리킵니다. 두 낱말이 함께 나오는 글을 읽을 때는 어느 뜻으로 썼는지 먼저 봅니다. 다만 이렇게 가르지 않고 지연을 응답 시간과 같은 넓은 뜻으로 쓰는 이름도 많습니다.

서버가 잰 값과 클라이언트가 잰 값

같은 요청이어도 누가 재느냐에 따라 값이 다릅니다. 서버는 보통 요청을 큐에서 꺼내 처리를 시작한 때부터 응답을 내보낸 때까지를 잽니다. 이 값에는 네트워크 구간이 빠집니다. 재기 시작하는 때가 큐를 지난 뒤이므로 큐에서 기다린 대기 구간도 빠집니다.

클라이언트가 잰 값에는 그 구간이 모두 들어갑니다. 그래서 서버 로그에서는 빠른데 사용자는 느리다고 하는 일이 생깁니다. 응답 시간 두 개를 견줄 때는 어디서 잰 값인지부터 맞춥니다.

부하 테스트는 요청을 일부러 많이 보내 시스템이 어떻게 버티는지 보는 시험입니다. 부하 테스트 도구는 요청을 보내는 쪽에서 응답 시간을 잽니다. 사용자가 겪는 시간에 가까운 값을 얻으려는 것입니다.

평균 대신 백분위수

요청마다 응답 시간이 다릅니다. 그래서 여러 건을 몇 개의 값으로 줄여서 봅니다. 가장 쉬운 방법은 평균입니다. 그런데 평균은 느린 요청 몇 건을 가립니다.

백분위수는 값을 빠른 순서로 줄 세운 뒤 몇 번째 값인지로 읽는 방법입니다. 100건 중 99번째로 빠른 값이 99번째 백분위수입니다. 흔히 p99 라고 줄여 적습니다.

중앙값은 줄 세운 값의 한가운데 값입니다. 50번째 백분위수가 곧 중앙값입니다.

요청 100건을 예로 들어 봅니다. 95건은 0.1초에 끝났고 5건은 2초가 걸렸다고 합시다. 같은 100건을 네 가지로 읽으면 이렇습니다.

평균 0.195초만 보면 모두가 0.2초쯤 기다린 것처럼 읽힙니다. 표를 보면 95건은 그보다 빨랐고 5건은 열 배 넘게 느렸습니다. 느린 5건은 99번째 백분위수에서야 드러납니다.

가장 느린 쪽의 응답 시간을 꼬리 지연이라고 부릅니다. 이 이름의 「지연」은 앞에서 가른 한 구간이라는 좁은 뜻이 아닙니다. 응답 시간과 같은 넓은 뜻입니다.

한 화면을 그리려고 서버 여러 곳을 부르면 그중 하나만 느려도 화면 전체가 늦어집니다. 부르는 곳이 많을수록 가장 느린 쪽 응답을 겪는 사용자가 늘어납니다.

백분위수 말고 시간 범위로 세는 방법도 있습니다. 「1초 미만 몇 건, 1초에서 2초 사이 몇 건, 그 이상 몇 건」처럼 셉니다.

붐빌수록 가파르게 늘어나는 까닭

서버가 한가할 때는 요청이 도착하자마자 처리됩니다. 대기 구간이 거의 없으니 응답 시간은 처리 구간과 비슷합니다.

들어오는 요청이 서버가 끝낼 수 있는 양에 가까워지면 달라집니다. 요청은 고르게 오지 않고 몰렸다 비었다 합니다. 몰린 순간에 생긴 줄이 다 빠지기 전에 다음 무리가 도착합니다.

대기 구간은 부하에 맞춰 조금씩 늘지 않습니다. 한계에 가까워질수록 급하게 늘어납니다. 줄이 길어지는 이 모양을 수식으로 다루는 분야가 큐잉 이론입니다.

처리량은 정해진 시간 동안 끝낸 요청 수입니다. 처리량만 보면 요청 한 건이 얼마나 기다렸는지는 안 보입니다. 한계 근처에서는 처리량이 더 오르지 않습니다. 응답 시간만 늘어납니다. 부하 테스트는 요청을 조금씩 늘리며 처리량은 멈추고 응답 시간이 치솟기 시작하는 지점을 찾습니다.

실패한 요청의 응답 시간

실패한 요청에도 응답 시간이 있습니다. 다만 성공한 요청과 한데 섞어 계산하면 값이 틀어집니다.

데이터베이스 연결이 끊긴 서버는 일을 하지 않고 곧장 오류를 돌려줍니다. 이런 오류 응답은 아주 빠릅니다. 섞어 계산하면 장애가 난 순간 응답 시간이 오히려 좋아진 것처럼 보입니다.

타임아웃은 기다릴 최대 시간을 정해 두고 넘으면 실패로 끊는 장치입니다. 타임아웃으로 끝난 요청은 제한 시간만큼 걸린 것으로 찍힙니다. 서버가 얼마나 더 걸렸을지는 이 값이 알려 주지 않습니다. 그래서 성공과 실패를 갈라 따로 봅니다.

목표로 거는 응답 시간

팀은 응답 시간에 목표를 걸어 둡니다. 「100건 중 99건이 0.3초 안에 끝난다」처럼 백분위수와 시간을 짝지어 적습니다.

서비스가 지킬 수준을 이렇게 숫자로 정한 것을 서비스 수준 목표라고 합니다. 목표가 있으면 배포 뒤에 응답 시간이 나빠졌는지를 한 번에 판정할 수 있습니다.

관련 항목

응답 시간과 함께 서비스를 재는 지표

지연 · 처리량 · 오류율 · 포화도 · 초당 요청 수 · 서비스 수준 지표

응답 시간 분포를 읽는 통계

평균 · 중앙값 · 백분위수 · 꼬리 지연 · 히스토그램

응답 시간을 이루는 구간

네트워크 지연 · 왕복 시간 · 큐 · 대기 시간 · 처리 시간 · 첫 바이트까지의 시간

응답 시간을 늘리는 원인

병목 · 큐잉 이론 · 가비지 컬렉션 · 락 경합 · 커넥션 풀 · 콜드 스타트

응답 시간을 재고 지키는 활동과 도구

부하 테스트 · 성능 테스트 · Gatling · Locust · 모니터링 · 서비스 수준 목표 · 타임아웃

응답 시간을 줄이는 수단

캐싱 · 수평 확장 · 로드 밸런서 · 비동기 처리 · CDN

응답 시간을 겪고 재는 참여자

클라이언트 · 서버 · 데이터베이스 · 브라우저 · 프로세스