Patchwork D1932: bundle2: increase payload part chunk size to 32kb

indygreg created this revision.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.

REVISION SUMMARY
  Bundle2 payload parts are framed chunks. Esentially, we obtain
  data in equal size chunks of size `preferedchunksize` and emit those
  to a generator. That generator is fed into a compressor (which can
  be the no-op compressor, which just re-emits the generator). And
  the output from the compressor likely goes to a file descriptor
  or socket.
  
  What this means is that small chunk sizes create more Python objects
  and Python function calls than larger chunk sizes. And as we know,
  Python object and function call overhead in performance sensitive
  code matters (at least with CPython).
  
  This commit increases the bundle2 part payload chunk size from 4k
  to 32k. Practically speaking, this means that the chunks we feed
  into a compressor (implemented in C code) or feed directly into a
  file handle or socket write() are larger. It's possible the chunks
  might be larger than what the receiver can handle in one logical
  operation. But at that point, we're in C code, which is much more
  efficient at dealing with splitting up the chunk and making multiple
  function calls than Python is.
  
  A downside to larger chunks is that the receiver has to wait for that
  much data to arrive (either raw or from a decompressor) before it
  can process the chunk. But 32kb still feels like a small buffer to
  have to wait for. And in many cases, the client will convert from
  8 read(4096) to 1 read(32768). That's happening in Python land. So
  we cut down on the number of Python objects and function calls,
  making the client faster as well. I don't think there are any
  significant concerns to increasing the payload chunk size to 32kb.
  
  The impact of this change on performance significant. Using `curl`
  to obtain a stream clone bundle2 payload from a server on localhost
  serving the mozilla-unified repository:
  
  before: 20.78 user; 7.71 system;  80.5 MB/s
  after:  13.90 user; 3.51 system; 132 MB/s
  legacy:  9.72 user; 8.16 system; 132 MB/s
  
  bundle2 stream clone generation is still more resource intensive than
  legacy stream clone (that's likely because of the use of a
  util.chunkbuffer). But the throughput is the same. We might
  be in territory we're this is effectively a benchmark of the
  networking stack or Python's syscall throughput.
  
  From the client perspective, `hg clone -U --stream`:
  
  before: 33.50 user; 7.95 system; 53.3 MB/s
  after:  22.82 user; 7.33 system; 72.7 MB/s
  legacy: 29.96 user; 7.94 system; 58.0 MB/s
  
  And for `hg clone --stream` with a working directory update of
  ~230k files:
  
  after:  119.55 user; 26.47 system; 0:57.08 wall
  legacy: 126.98 user; 26.94 system; 1:05.56 wall
  
  So, it appears that bundle2's stream clone is now definitively faster
  than legacy stream clone!

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D1932

AFFECTED FILES
  mercurial/bundle2.py
  tests/test-clone-uncompressed.t

CHANGE DETAILS




To: indygreg, #hg-reviewers
Cc: mercurial-devel

lothiraldan added a comment.


  The improvement seems nice for the stream but it might have unintended consequences on other network operations. Would it be possible to introduce a config knob to restore the old value or tune it later?

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D1932

To: indygreg, #hg-reviewers
Cc: lothiraldan, mercurial-devel

indygreg added a comment.


  In https://phab.mercurial-scm.org/D1932#32544, @lothiraldan wrote:
  
  > The improvement seems nice for the stream but it might have unintended consequences on other network operations. Would it be possible to introduce a config knob to restore the old value or tune it later?
  
  
  I agree a commit knob would be useful. Could be done as a follow-up easily enough.
  
  As to whether this will have an impact on other network operations, I'm skeptical. I'm pretty sure we already use 32kb chunks in other places. And, the SSH protocol today may not do any buffering, meaning that each chunk from the iterator gets turned into a socket.send(). That may be creating a ton of TCP overhead...

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D1932

To: indygreg, #hg-reviewers
Cc: lothiraldan, mercurial-devel

durin42 added a comment.


  In https://phab.mercurial-scm.org/D1932#32544, @lothiraldan wrote:
  
  > The improvement seems nice for the stream but it might have unintended consequences on other network operations. Would it be possible to introduce a config knob to restore the old value or tune it later?
  
  
  If I'm understanding this right, it's a server-side-only change, so I'd rather defer the knob until we have a benchmark that shows this is detrimental.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D1932

To: indygreg, #hg-reviewers
Cc: durin42, lothiraldan, mercurial-devel