Uploaded image for project: 'Thrift'
  1. Thrift
  2. THRIFT-5192

Is the buffered transport much slower?

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Open
    • Minor
    • Resolution: Unresolved
    • 0.13.0
    • None
    • C++ - Library

    Description

      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?

      Attachments

        Activity

          People

            Unassigned Unassigned
            emmenlau Mario Emmenlauer
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated: