You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Mario Emmenlauer (Jira)" <ji...@apache.org> on 2020/04/30 12:56:00 UTC

[jira] [Created] (THRIFT-5192) Is the buffered transport much slower?

Mario Emmenlauer created THRIFT-5192:
----------------------------------------

             Summary: Is the buffered transport much slower?
                 Key: THRIFT-5192
                 URL: https://issues.apache.org/jira/browse/THRIFT-5192
             Project: Thrift
          Issue Type: Improvement
    Affects Versions: 0.13.0
            Reporter: Mario Emmenlauer


I've used the current HEAD version of thrift for a benchmark of various transports, protocols, servers etc. My focus right now is on throughput on the local machine, so getting as many bytes as possible from one process to another in a short amount of time.

Generally, the good news, first, Thrift can be very fast and on a range of modern desktop computers I get a top throughput between processes in the range of 4-6Gb/sec.

But there is one aspect that is striking: There is one transport that performs worse than what I would have expected, and this is the "buffered" transport. As an example, I can achieve around 5Gb/sec with a plain domain socket transport, and still an impressive 3.6Gb/sec by wrapping a "framed" transport. Wrapping with a "header" transport still gives 3.3Gb/sec, and the fastest "http" transport achieves 2.6Gb/sec.

Then comes a huge gap, before the fastest contestant with "buffered" transport shows up with 1.3Gb/sec.

Does anybody have any hints as to why "buffered" may be so much slower? What is the difference between the buffering in "framed" that makes it almost 3 times faster?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)