Как ускорили Git push через HTTPS в Bitbucket Cloud в 8 раз

Введение

Bitbucket Cloud — платформа для хостинга и совместной работы с Git-репозиториями. Она поддерживает два основных протокола доступа: HTTPS и SSH. Оба используют общую инфраструктуру и одни и те же бэкенд-сервисы, но долгое время SSH заметно выигрывал в скорости при загрузке больших объёмов данных.

В марте 2022 года команды Atlassian устранили это неравенство — скорость push через HTTPS выросла до 8 раз. Если раньше импорт репозитория размером 2 ГБ мог занимать два часа, то теперь на ту же задачу уходит около 15 минут.

В этой статье — как команды Atlassian Networking Edge Services и Bitbucket Cloud совместно решали проблему: от первых подозрений до деплоя фикса и реальных результатов для пользователей. Это инженерный кейс Atlassian, опубликованный как разбор практики.

Как обнаружили проблему

Проблема всплыла во время подготовки Bitbucket Cloud Migration Assistant — инструмента для миграции крупных инсталляций Data Center в облако. В ходе нагрузочного тестирования один из инженеров заметил аномалию при заливке большого репозитория с инстанса в AWS Sydney:

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

Скорость была катастрофически низкой — около 250 КБ/с. Для клиентов с терабайтными репозиториями это означало бы дни простоя. Так родилась задача: найти узкое место и устранить его.

1. Сетевая файловая система — не виновата

Первая гипотеза — проблемы с общей сетевой файловой системой, где хранятся репозитории. Тест: один и тот же репозиторий, один клиент, два протокола.

Оба запроса пишут в одну ФС, но скорость кардинально отличается. Значит, проблема не в дисковом вводе-выводе.

2. География — не главный фактор

Следующее предположение — задержки между Австралией и США (основной дата-центр Bitbucket — на восточном побережье США). Тесты с разных машин и регионов:

Результат не коррелировал с геолокацией. Клиенты в одном регионе показывали разную скорость. Значит, дело не в расстоянии до сервера.

3. Edge-слой и загадка окон

Подключили команду Edge-сервисов. Захват пакетов на балансировщиках сравнил медленный и быстрый push-сеансы. Обнаружилось два важных отличия:

• Размер receive window (окно приёма) для медленных клиентов был искусственно ограничен и «упирался в потолок».
• HTTP-протокол: быстрые клиенты использовали HTTP/1.1, медленные — HTTP/2.

Это был ключевой момент: именно версия протокола коррелировала с производительностью. Проверочный тест на одном клиенте подтвердил:

Вскрытие: неоптимальные настройки HTTP/2

В конфигурации Edge-балансировщика параметры HTTP/2 (буферы соединений, размеры фреймов) были оставлены «по умолчанию». Для мелких запросов это не страшно, но на больших репозиториях становилось узким горлышком.

Тестовые изменения на небоевом балансировщике:

Рост — в 23 раза. Проблема решалась настройкой трёх параметров:

• Max Frame Size — максимальный размер кадра от клиента.
• Preferred Frame Size — предпочтительный размер кадра.
• Stream Buffer Size — объём памяти под буферизацию входящих пакетов.

Эти параметры напрямую влияют на управление потоком (flow control) и динамически регулируют receive window. Увеличение значений снимает искусственный лимит.

Результаты и влияние на клиентов

Большинство push-запросов в Bitbucket Cloud — маленькие (сотни килобайт), поэтому на них замедление было незаметно. Для крупных импортов (например, при переходе с Data Center в облако) разница стала драматичной.

Что получили пользователи:

• В «патологических» случаях (высокая задержка + высокая пропускная способность) прирост достигал 70 раз.
• В реальной эксплуатации, спустя неделю после релиза, ускорение составило от 2 до 8 раз в зависимости от часовой зоны и средней задержки региона.

Графики показывали явную корреляцию: чем выше латентность у клиента, тем больше он выигрывал от оптимизации.

Выводы

• Внимание к протоколам. Переход на HTTP/2 обычно полезен, но настройки нужно проверять под свою нагрузку.
• Совместная работа — ключ. Без Edge-команды расследование заняло бы в разы больше времени.

Этот кейс — классический пример того, как инженерная дотошность и кросс-командное взаимодействие превращают «магический» баг в решаемую задачу.

Часто задаваемые вопросы

Почему HTTPS push в Bitbucket Cloud был медленнее SSH?

Оба протокола писали в одну файловую систему, но медленные HTTPS-клиенты шли по HTTP/2 с дефолтными настройками Edge: receive window упирался в искусственный потолок. SSH и HTTP/1.1 такого лимита не ловили.

Насколько ускорили push через HTTPS после фикса?

Импорт репозитория на 2 ГБ сократился примерно с двух часов до 15 минут. В бою через неделю после релиза ускорение составило от 2 до 8 раз; в патологических случаях — до 70 раз.

В чём была корневая причина, если не диск и не география?

Скорость коррелировала с версией HTTP: HTTP/1.1 давал около 2 МБ/с, HTTP/2 — около 300 КБ/с. Узкое место — дефолтные параметры HTTP/2 на Edge-балансировщике.

Какие параметры HTTP/2 изменили?

Max Frame Size, Preferred Frame Size и Stream Buffer Size. На тестовом балансировщике скорость выросла с 321 КБ/с до 7.46 МБ/с — примерно в 23 раза.

Почему обычные маленькие push почти не страдали?

Большинство push в Bitbucket Cloud — сотни килобайт. Дефолтных буферов HTTP/2 хватало. Узкое место проявлялось на крупных импортах, например при миграции Data Center в облако.

Кому сильнее помогла оптимизация?

Чем выше латентность у клиента, тем больше выигрыш. Спустя неделю после релиза ускорение от 2 до 8 раз зависело от средней задержки региона.