[
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)
