[ Server ] Performance Analyzer

https://github.com/triton-inference-server/server/blob/main/docs/perf_analyzer.md 

 

Performance Analyzer

모델의 inference 성능을 최적화하는데 중요한 점은, 최적화 전략을 달리해서 실험할 때, 성능의 변화를 측정할 수 있는 지의 여부이다.

perf_analyzer application은 triton 서버에서 이 작업을 수행한다.

 

perf_analyzer 어플리케이션은 inference 요청을 생성하여 모델에 보내고, throughput 과 latency를 측정한다.

representative results를 얻기 위해, 값이 안정화될 때까지 반복해서 측정한다.

기본적으로 안정을 결정하는데 평균 latency를 사용하지만, --percentile flag를 사용하여 해당 신뢰도 수준에 따라 결과를 안정화시킬 수 있다.

For example, if --percentile=95 is used the results will be stabilized using the 95-th percentile request latency.

예를 들어, --percentile=95 일 때, request latency의 95th percentile을 사용해서 결과를 안정화 시킨다.

아래에서 실행 코드와 결과를 보여준다.

$ perf_analyzer -m inception_graphdef --percentile=95
*** Measurement Settings ***
  Batch size: 1
  Measurement window: 5000 msec
  Using synchronous calls for inference
  Stabilizing using p95 latency

Request concurrency: 1
  Client:
    Request count: 348
    Throughput: 69.6 infer/sec
    p50 latency: 13936 usec
    p90 latency: 18682 usec
    p95 latency: 19673 usec
    p99 latency: 21859 usec
    Avg HTTP time: 14017 usec (send/recv 200 usec + response wait 13817 usec)
  Server:
    Inference count: 428
    Execution count: 428
    Successful request count: 428
    Avg request latency: 12005 usec (overhead 36 usec + queue 42 usec + compute input 164 usec + compute infer 11748 usec + compute output 15 usec)

Inferences/Second vs. Client p95 Batch Latency
Concurrency: 1, throughput: 69.6 infer/sec, latency 19673 usec

Request Concurrency

기본적으로 perf_analyzer 는 모델의 latency 와 throughput을 모델에 가장 적은 load가 걸리도록 하여 측정한다.

이렇게 측정하기 위해, perf_analyzer 는 triton으로 하나의 inference request를 보내고, 응답이 올 때까지 기다린다.

응답이 도착하면 즉시 다른 요청을 보내고, 이를 반복한다.

outstanding inference 요청의 수를 request concurrency 라고 하고, 기본적으로 1로 설정되어 있다.

 

--concurrency-range <start>:<end>:<step> 옵션을 사용하여, request concurrency 범위에 따른 데이터를 모을 수 있다.

--help 옵션으로 다른 옵션을 볼 수도 있다.

request concurrency 값의 범위가 1~4 일 때, latency 와 throughput 의 결과를 아래와 같이 확인할 수 있다.

$ perf_analyzer -m inception_graphdef --concurrency-range 1:4
*** Measurement Settings ***
  Batch size: 1
  Measurement window: 5000 msec
  Latency limit: 0 msec
  Concurrency limit: 4 concurrent requests
  Using synchronous calls for inference
  Stabilizing using average latency

Request concurrency: 1
  Client:
    Request count: 339
    Throughput: 67.8 infer/sec
    Avg latency: 14710 usec (standard deviation 2539 usec)
    p50 latency: 13665 usec
...
Request concurrency: 4
  Client:
    Request count: 415
    Throughput: 83 infer/sec
    Avg latency: 48064 usec (standard deviation 6412 usec)
    p50 latency: 47975 usec
    p90 latency: 56670 usec
    p95 latency: 59118 usec
    p99 latency: 63609 usec
    Avg HTTP time: 48166 usec (send/recv 264 usec + response wait 47902 usec)
  Server:
    Inference count: 498
    Execution count: 498
    Successful request count: 498
    Avg request latency: 45602 usec (overhead 39 usec + queue 33577 usec + compute input 217 usec + compute infer 11753 usec + compute output 16 usec)

Inferences/Second vs. Client Average Batch Latency
Concurrency: 1, throughput: 67.8 infer/sec, latency 14710 usec
Concurrency: 2, throughput: 89.8 infer/sec, latency 22280 usec
Concurrency: 3, throughput: 80.4 infer/sec, latency 37283 usec
Concurrency: 4, throughput: 83 infer/sec, latency 48064 usec

 

Understanding The Output

각 request concurrency 수준에 대하여 perf_analyzer는 client(perf_analyzer)에게 보여지는 latency 와 throughput 과, 서버에서의 평균 request latency가 저장된다.

 

server latency 는 서버가 요청을 받을 때부터, 서버가 등답을 보낼 때까지의 전체 시간을 측정한다.

Because of the HTTP and GRPC libraries used to implement the server endpoints, total server latency is typically more accurate for HTTP requests as it measures time from first byte received until last byte sent.

HTTP, GRPC 의 경우 총 server latency는 아래 두 가지로 구성된다.

• queue
• compute

client latency 는 HTTP, GRPC 에 따라 더 세분화 된다.

• HTTP
• GRPC

 

 

 

Visualizing Latency vs Throughput

-f 옵션을 통해서 결과를 CSV 파일로 저장할 수 있다.

$ perf_analyzer -m inception_graphdef --concurrency-range 1:4 -f perf.csv
$ cat perf.csv
Concurrency,Inferences/Second,Client Send,Network+Server Send/Recv,Server Queue,Server Compute Input,Server Compute Infer,Server Compute Output,Client Recv,p50 latency,p90 latency,p95 latency,p99 latency
1,69.2,225,2148,64,206,11781,19,0,13891,18795,19753,21018
3,84.2,237,1768,21673,209,11742,17,0,35398,43984,47085,51701
4,84.2,279,1604,33669,233,11731,18,1,47045,56545,59225,64886
2,87.2,235,1973,9151,190,11346,17,0,21874,28557,29768,34766

엑셀을 통해 결과와 latency vs inferences/second tradeoff 를 쉽게 확인할 수 있다.

 

Input Data

기본적으로 랜덤한 데이터를 모델에 입력으로 넣어준다.

--input-data 옵션을 통해서 다른 입력 데이터를 넣어줄 수도 있다.

 

• random : (default) 랜덤 데이터를 input으로 보냄
• zero : 0을 입력으로 보냄
• directory path : binary file을 포함하는 디렉토리를 입력으로 보냄
• file path : JSON file 을 입력으로 보냄

string/bytes 데이터 타입의 경우 --string-length, --string-data 옵션을 추가로 사용할 수 있다.

 

Real Input Data

실제 입력을 계속 넣어주기 위함이 아닐까

 

 

Shared Memory