summaryrefslogtreecommitdiff
path: root/Documentation/RelNotes/1.6.5.9.txt
diff options
context:
space:
mode:
authorLibravatar Jacob Vosmaer <jacob@gitlab.com>2021-12-14 20:46:26 +0100
committerLibravatar Junio C Hamano <gitster@pobox.com>2021-12-15 11:51:18 -0800
commit55a9651d26a6b88c68445e7d6c9f511d1207cbd8 (patch)
tree7ba21f99e6540f7f2a5f3cd35950183c9b5a8d00 /Documentation/RelNotes/1.6.5.9.txt
parentThe third batch (diff)
downloadtgif-55a9651d26a6b88c68445e7d6c9f511d1207cbd8.tar.xz
upload-pack.c: increase output buffer size
When serving a fetch, git upload-pack copies data from a git pack-objects stdout pipe to its stdout. This commit increases the size of the buffer used for that copying from 8192 to 65515, the maximum sideband-64k packet size. Previously, this buffer was allocated on the stack. Because the new buffer size is nearly 64KB, we switch this to a heap allocation. On GitLab.com we use GitLab's pack-objects cache which does writes of 65515 bytes. Because of the default 8KB buffer size, propagating these cache writes requires 8 pipe reads and 8 pipe writes from git-upload-pack, and 8 pipe reads from Gitaly (our Git RPC service). If we increase the size of the buffer to the maximum Git packet size, we need only 1 pipe read and 1 pipe write in git-upload-pack, and 1 pipe read in Gitaly to transfer the same amount of data. In benchmarks with a pure fetch and 100% cache hit rate workload we are seeing CPU utilization reductions of over 30%. Signed-off-by: Jacob Vosmaer <jacob@gitlab.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/RelNotes/1.6.5.9.txt')
0 files changed, 0 insertions, 0 deletions