처리량(throughput)은 시스템 성능에서 단위 시간 동안 완료되는 작업량을 뜻한다. 웹 서버에서는 초당 요청 수(rps)로, 저장 장치에서는 초당 전송량으로, 작업 큐에서는 시간당 처리 건수로 나타낼 수 있다. 지연시간이 개별 작업의 소요 시간을 본다면, 처리량은 시스템 전체의 처리 용량을 본다.[1][2]
1. 개요
처리량은 시스템이 일정한 시간창 안에서 얼마만큼의 작업을 끝낼 수 있는지를 보여 주는 지표다. 같은 하드웨어라도 작업의 크기, 동시성 수준, 네트워크 상태, 브라우저나 클라이언트의 처리 방식에 따라 체감 처리량은 달라진다.[2][5] 그래서 처리량은 절대적인 숫자 하나보다, 어떤 부하 모델에서 측정했는지가 더 중요하다.
부하 테스트에서는 처리량을 통해 시스템의 상한을 가늠한다. 요청이 증가해도 처리량이 함께 늘지 않거나 오히려 줄어든다면 병목이 발생한 신호일 수 있다.[3] 반대로 처리량이 높더라도 지연시간이 길다면 사용자 경험은 나빠질 수 있으므로 두 지표를 함께 보아야 한다.[1][5]
2. 지연시간과의 관계
지연시간은 하나의 요청이나 작업이 시작되어 끝나기까지 걸리는 시간이고, 처리량은 그 시간 동안 시스템이 끝낸 작업의 총량이다. 처리시간이 짧다고 해서 반드시 처리량이 높은 것은 아니며, 반대로 처리량이 높다고 해서 개별 요청이 빨리 끝나는 것도 아니다.[2][5]
이 차이는 시스템 성능을 해석할 때 중요하다. 예를 들어 웹 애플리케이션은 응답이 빠르지만 동시 접속이 늘면 처리량이 먼저 포화될 수 있고, 동영상 스트리밍 서비스는 대역폭과 데이터 전송 속도가 넉넉해도 버퍼링이 생기면 체감 품질이 떨어질 수 있다.[3][5] 따라서 성능 평가에서는 처리량과 지연시간을 분리해서 읽어야 한다.
3. 측정 단위
4. 시스템 설계에서의 의미
처리량을 높이려면 시스템은 병목을 줄이고, 유휴 시간을 줄이고, 컴퓨터 자원을 더 잘 활용해야 한다. 일반적으로는 병렬 처리, 큐잉, 캐시, 배치, 요청 분산 같은 방법이 쓰이며, 목표는 자원 관리를 안정적으로 유지하면서 더 많은 작업을 완료하는 것이다.[1][3][5]
운영체제와 멀티프로그래밍 관점에서는 여러 프로세스를 동시에 메모리에 두고 CPU 사용률을 높여 전체 처리량을 끌어올리려 한다. 이 과정에서 스케줄링 정책은 매우 중요하며, 처리량을 무리하게 키우면 지연시간이 악화될 수 있다. 따라서 시스템은 성능과 자원 효율성 사이의 균형을 맞춰야 한다.[3][5]
5. 해석할 때 주의할 점
처리량은 크면 무조건 좋은 지표처럼 보이지만, 실제로는 측정 범위와 시간 구간을 잘못 잡으면 오해를 낳기 쉽다. 예를 들어 짧은 순간의 평균 처리량은 안정적으로 보이더라도, 피크 구간에서는 인터넷 환경이나 네트워크 혼잡 때문에 급격히 떨어질 수 있다.[2][5]
또한 처리량 개선이 항상 사용자 만족으로 이어지는 것도 아니다. 내부 파이프라인의 배치를 키워 처리량을 높였더라도, 개별 요청의 완료 시간이 길어지면 사용자는 느린 시스템으로 느낄 수 있다. 그래서 실무에서는 처리량과 지연시간을 함께 보고, 둘 중 하나만으로 결론을 내리지 않는다.[1][3]
8. 인용 및 각주
[1] Top Metrics for Benchmarking IT System Performance, CTOX, ctox.com(새 탭에서 열림)
[2] latency와 throughput 이란, gaussian37, gaussian37.github.io(새 탭에서 열림)
[3] Systems Performance - #2 Methodologies, Velog, velog.io(새 탭에서 열림)
[4] Throughput과 Latency, Velog, velog.io(새 탭에서 열림)
[5] 처리량(Throughput)과 지연시간(Latency) - 속도의 본질 파헤치기, Velog, velog.io(새 탭에서 열림)