HBase
  1. HBase
  2. HBASE-11504

Don't flush the socket buffer for each response

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 0.99.0
    • Fix Version/s: None
    • Component/s: Client, regionserver
    • Labels:
      None

      Description

      today we flush the socket buffer after each response.

      The server maintains a queue of the calls to write. If this queue is not empty, we should not flush. We should do that only when the queue is empty. This will save some packets when nagle is disabled and we have a list of small responses to send (for example responses to puts, or small gets). This is linked to HBASE-11492.

      The client has a queue as well, so we could do the same thing there.

      There could be some drawbacks (if the server is overloaded between multiple channel for example writing the next response may take time), but it seems a good thing to do. For example, if the server if overloaded saving on buffer flush seems to be a nice thing to do.

      Any opinion?
      It's something I plan to do if I don't find a major drawback.

        Activity

        Hide
        Nicolas Liochon added a comment -

        Actually:

        • server side, as we use nio, there is no flush. The writes go directly to the socket buffer. We may send too much packet because of this, but it's not sure, and it's another question
        • client side it would make sense, ats we're still on oio, but it leads so some race conditions if the delay the flush while we cancel a message. It's not that difficult to solve, but it adds some extra complexity on something complex enough already.

        => Solving as won't fix for now.

        Show
        Nicolas Liochon added a comment - Actually: server side, as we use nio, there is no flush. The writes go directly to the socket buffer. We may send too much packet because of this, but it's not sure, and it's another question client side it would make sense, ats we're still on oio, but it leads so some race conditions if the delay the flush while we cancel a message. It's not that difficult to solve, but it adds some extra complexity on something complex enough already. => Solving as won't fix for now.
        Hide
        Andrew Purtell added a comment -

        No patch yet, moving to 0.98.6

        Show
        Andrew Purtell added a comment - No patch yet, moving to 0.98.6
        Hide
        Andrew Purtell added a comment -

        This sounds reasonable. Also something that could be checked for perf regressions with YCSB

        Show
        Andrew Purtell added a comment - This sounds reasonable. Also something that could be checked for perf regressions with YCSB

          People

          • Assignee:
            Nicolas Liochon
            Reporter:
            Nicolas Liochon
          • Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development