임시 - designing data-intensive application - Describing performance

In a batch-processing system such as Hadoop, we usually care about throughput—the number of records we can process per second, or the total time it takes to run a job on a dataset of a certain size

하둡 같은 배치 시스템에서 성능 지표는 소위 말하는 스루풋 (초당 처리해야할 레코드의 수) 이나 일정 사이즈로 어떤 데이터셋을 처리하는 총 시간등이다. 

In online systems, latency is usually more important—the time it takes to serve a request, also known as response time.

온라인 시스템에서는 응답시간이라고 알려진 지표 - 각각의 요청을 처리하는데 걸린 시간 - Latency

We therefore need to think of latency not as a single number, but as a probability distribution.

latency는 측정할 때 마다 살짝 달라질 수 있어서 단일 수치로 취급하지말고 정규분포 형태로 취급해야 한다.

Now, when testing a system at various levels of load, you can track the median and higher percentiles of response times in order to get a quick measure of the performance.

다양한 부하를 받는 시스템을 테스트 하기 위해서는 평균 대신 중앙값 이나 상위의 percentile  백분위 계수(뭔가 퍼포먼스가 제일 떨어지는 놈)를 사용해야 한다.

90	59.7	평균
70	70	중간값
80	80	percentile 상위 80%
70
1
1
65
70
80
70

High percentiles become especially important in backend services that are called multiple times as part of serving a single end-user request. Even if you make the calls in parallel, the end-user request still needs to wait for the slowest of the parallel calls to complete

대박 중요 (왜 굳이 상위 백분위 계수의 값이 (즉 성능이 떨어지는 최악의 수치들이) 중요한 이유는 병렬처리 환경에서 저렇게 편차를 보이는 퍼포먼스가 나왔을때 결국 그 병렬처리의 끝은 맨 마지막에 끝난 놈의 수치가 퍼포먼스가 되기 때문에....)