Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Perf_analyzer reported metrics for decoupled model #7203

Open
ZhanqiuHu opened this issue May 10, 2024 · 4 comments
Open

Perf_analyzer reported metrics for decoupled model #7203

ZhanqiuHu opened this issue May 10, 2024 · 4 comments
Labels
question Further information is requested

Comments

@ZhanqiuHu
Copy link

I am trying to profile our decoupled models (python backend) with perf_analyzer, and I'm curious how the following latency metrics are calculated?

Client Send, Network+Server Send/Recv,Server Queue,Server Compute Input,Server Compute Infer,Server Compute Output, and Client Recv

Also, when using grpc or http endpoints, is it possible to measure the latencies spend on network overhead and (un)marshalling protobuf?

Thanks!

@nv-hwoo
Copy link
Contributor

nv-hwoo commented May 15, 2024

Hi @ZhanqiuHu,

I am trying to profile our decoupled models (python backend) with perf_analyzer, and I'm curious how the following latency metrics are calculated?

Please see here for the details of the metrics being calculated.

Also, when using grpc or http endpoints, is it possible to measure the latencies spend on network overhead and (un)marshalling protobuf?

I believe if you run perf analyzer with -i grpc, you should see output like this

*** Measurement Settings ***
  Batch size: 1
  Service Kind: Triton
  Using "time_windows" mode for stabilization
  Measurement window: 5000 msec
  Using synchronous calls for inference
  Stabilizing using average latency

Request concurrency: 1
  Client:
    Request count: 30375
    Throughput: 1685.54 infer/sec
    Avg latency: 591 usec (standard deviation 144 usec)
    p50 latency: 569 usec
    p90 latency: 710 usec
    p95 latency: 891 usec
    p99 latency: 1105 usec
    Avg gRPC time: 578 usec ((un)marshal request/response 6 usec + response wait 572 usec)
  Server:
    Inference count: 30376
    Execution count: 30376
    Successful request count: 30376
    Avg request latency: 319 usec (overhead 107 usec + queue 26 usec + compute input 46 usec + compute infer 85 usec + compute output 53 usec)

Inferences/Second vs. Client Average Batch Latency
Concurrency: 1, throughput: 1685.54 infer/sec, latency 591 usec

@nv-hwoo nv-hwoo added the question Further information is requested label May 15, 2024
@ZhanqiuHu
Copy link
Author

Thanks a lot for providing the details! I was more interested in what "Compute Input", "Compute Output", and "Network+Server Send/Recv" specifically are. When I use -i grpc the flag, it doesn't seem to report the gRPC time, and I was wondering if it is because I'm using a custom decoupled python model.

Thank you very much!

@nv-hwoo
Copy link
Contributor

nv-hwoo commented May 16, 2024

For compute input, compute infer, and compute output metrics, you could read the Triton doc here for more details.

When I use -i grpc the flag, it doesn't seem to report the gRPC time, and I was wondering if it is because I'm using a custom decoupled python model.

Yes you are correct. The gRPC time reports are not supported in decoupled model.

@ZhanqiuHu
Copy link
Author

Thanks for the answer! However, it seems like the description on the doc is a little bit vague. What specific steps are involved in preprocessing of inputs and outputs? For example, for inputs, copying/moving the data to the device is probably part of it? And I guess for decoupled python model, (de)serailization will be part of comptue infer time rather than compute input or compute output time?

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Development

No branches or pull requests

2 participants