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

["Jens Geyer (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-5192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097327#comment-17097327 ] 

Jens Geyer commented on THRIFT-5192:
------------------------------------

I have observed similar things with (IIRC) netstd, found it strange as well. Didn't spend much time on it though.

> Is the buffered transport much slower?
> --------------------------------------
>
>                 Key: THRIFT-5192
>                 URL: https://issues.apache.org/jira/browse/THRIFT-5192
>             Project: Thrift
>          Issue Type: Improvement
>          Components: C++ - Library
>    Affects Versions: 0.13.0
>            Reporter: Mario Emmenlauer
>            Priority: Minor
>              Labels: benchmark, perfomance
>
> 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)