-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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: thrift filter decoding introduces high latency #13082
Labels
Comments
cc @rgs1 |
cc: @fishcakez |
2 tasks
I write a very draft pr to gain some thoughts on this. Can you take a look when you have time? Thanks ! |
@caitong93 nice! we can review & test it out on our end as well. |
Great ! I will make the pr ready for review soon. |
htuch
pushed a commit
that referenced
this issue
Nov 30, 2020
…t message (#13592) Fixes #13082 Support skip decoding data after metadata in the thrift message. In payload_passthrough mode, there are some issues: Envoy cannot detect some errors and exceptions ( e.g. a reply that contains exceptions ). It's possible to improve this by peeking beginning of the payload. payload_passthrough controls both request and response path. It can be split into two options if we want more fine-grained control. FilterStatus passthroughData(Buffer::Instance& data, uint64_t bytes_to_passthrough) will not prohibit custom filters to modify buffer. Now it is assumed custom filters won't do that, otherwise behavior is undefined. Risk Level: Medium Testing: unit test: config decoder router conn_manager integration: add an parameter payload_passthrough manual: send requests and verify responses Signed-off-by: Tong Cai <caitong93@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Title: thrift filter introduces high latency
Description:
I observed high latency(thrift decoding cost 10ms+) when using thrift filter. qps under 1000, request/response message size < 1MB, connections < 100 , cpu usage < 0.01 core
envoy version: 1.12 ( cherry-picked the lastest thrift filter commits)
thrift protocol: framed + binary
Analysis shows most time is spent on thrift decoding. After dig into the code, I found thrift filter decode the whole struct of message to memory and encode it. I use thrift filter for loadbalancing, only metadata is useful. In this case, thrift filter waste a lot time decoding the struct part.
I wonder if we can add support to thrift filter to send the struct part as a passthrough.
Logs:
By replaying traffic from production, I observed 14ms latency for decoding a 930648 bytes message.
Following is debug log for a single request. For more detail, see trace log https://drive.google.com/file/d/1jkSPDFQmWBpa4BXbFJcdeNLzV9uiASbH/view?usp=sharing
Flamegraph
https://drive.google.com/file/d/1QNHe3I_fbXJtRAPY0alCNUiNO80Zfgf3/view?usp=sharing
Configuration
The text was updated successfully, but these errors were encountered: