How Bitbucket Cloud sped up Git push over HTTPS by 8x

Introduction

Bitbucket Cloud is a platform for hosting and collaborating on Git repositories. It supports two main access protocols: HTTPS and SSH. Both share the same infrastructure and backend services, but for a long time SSH was clearly faster when uploading large amounts of data.

In March 2022 Atlassian teams closed that gap — HTTPS push throughput grew by up to 8x. A 2 GB repository import that could take two hours now finishes in about 15 minutes.

This article follows how Atlassian Networking Edge Services and Bitbucket Cloud solved it together: from the first suspicions to the deployed fix and real user impact. It is an Atlassian engineering case study, published as a practice write-up.

How the problem showed up

It surfaced while building Bitbucket Cloud Migration Assistant — a tool for moving large Data Center installs to the cloud. During load testing an engineer noticed an anomaly uploading a large repository from an instance in AWS Sydney:

Writing objects:   3% (814501/21340058), 176.92 MiB | 253.00 KiB/s

Throughput was catastrophically low — about 250 KB/s. For customers with terabyte-scale repositories that would mean days of downtime. The task was to find the bottleneck and remove it.

1. The network filesystem was not at fault

The first hypothesis was the shared network filesystem that stores repositories. The test: same repository, same client, two protocols.

Both requests write to the same filesystem, but the speeds are wildly different. So the problem was not disk I/O.

2. Geography was not the main factor

The next assumption was latency between Australia and the US (Bitbucket’s primary data center is on the US East Coast). Tests from different machines and regions:

The result did not correlate with location. Clients in the same region showed different speeds. So it was not distance to the server.

3. The edge layer and the window puzzle

The Edge services team joined. Packet captures on the load balancers compared a slow and a fast push session. Two differences stood out:

• The receive window for slow clients was artificially capped and hit a ceiling.
• HTTP version: fast clients used HTTP/1.1, slow ones used HTTP/2.

That was the turning point: protocol version correlated with performance. A check on a single client confirmed it:

Root cause: suboptimal HTTP/2 settings

On the Edge load balancer, HTTP/2 parameters (connection buffers, frame sizes) were left at defaults. Fine for small requests, but a bottleneck on large repositories.

A test change on a non-production balancer:

A 23x gain. The fix was three parameters:

• Max Frame Size — maximum frame size from the client.
• Preferred Frame Size — preferred frame size.
• Stream Buffer Size — memory for buffering incoming packets.

These settings drive flow control and dynamically size the receive window. Raising them removes the artificial cap.

Results and customer impact

Most Bitbucket Cloud pushes are small (hundreds of kilobytes), so the slowdown was invisible there. For large imports (for example Data Center to cloud) the difference was dramatic.

What users got:

• In pathological cases (high latency + high bandwidth) the gain reached 70x.
• In production, a week after release, speedup ranged from 2x to 8x depending on time zone and the region’s average latency.

The graphs showed a clear correlation: the higher the client latency, the more they gained from the optimization.

Takeaways

• Watch the protocol. Moving to HTTP/2 is usually good, but its settings need to match your workload.
• Cross-team work is the key. Without the Edge team the investigation would have taken far longer.

This case is a classic of how engineering thoroughness and cross-team collaboration turn a “magic” bug into a solvable problem.

Frequently asked questions

Why was HTTPS push in Bitbucket Cloud slower than SSH?

Both protocols wrote to the same filesystem, but slow HTTPS clients went over HTTP/2 with default Edge settings: the receive window hit an artificial ceiling. SSH and HTTP/1.1 did not hit that cap.

How much faster did HTTPS push get after the fix?

A 2 GB repository import dropped from about two hours to 15 minutes. In production a week after release the speedup was 2x to 8x; in pathological cases, up to 70x.

What was the root cause if it was not disk or geography?

Speed correlated with HTTP version: HTTP/1.1 was about 2 MB/s, HTTP/2 about 300 KB/s. The bottleneck was default HTTP/2 parameters on the Edge load balancer.

Which HTTP/2 settings changed?

Max Frame Size, Preferred Frame Size, and Stream Buffer Size. On a test balancer, speed went from 321 KB/s to 7.46 MB/s — about 23x.

Why did ordinary small pushes barely suffer?

Most Bitbucket Cloud pushes are hundreds of kilobytes. Default HTTP/2 buffers were enough. The bottleneck showed up on large imports, such as Data Center to cloud migrations.

Who benefited most from the optimization?

The higher the client latency, the larger the gain. A week after release, the 2x–8x speedup tracked each region’s average delay.