Setki commitów na sekundę. Reason Machines udostępnia Aspen, serwer Gita dla agentów AI
Klasyczne serwery Gita projektowano z myślą o ludzkim rytmie pracy, w którym programista wysyła zmiany do repozytorium kilka razy dziennie. Gdy w jednym projekcie pracują dziesiątki lub setki agentów AI, repozytorium może stać się wąskim gardłem: agenci wysyłają zmiany co kilka minut, a po każdym pushu systemy ciągłej integracji odpytują serwer o nowe dane. Klasyczny serwer Gita kieruje wszystkie operacje push przez pojedynczą kolejkę dla całego repozytorium i generuje świeże archiwa obiektów (pliki pack) przy każdym pobraniu, przez co obciążenie maszyny rośnie wraz z liczbą klientów, a nie z ilością dopisanego kodu.
Na ten problem natknęło się wcześniej OpenAI, gdy agenci Codex przeciążyli wewnętrzne monorepo firmy. W odpowiedzi inżynierowie stworzyli własny backend o nazwie Pando, którego założenia opisano w tekście o skalowaniu Gita w OpenAI. Startup Reason Machines postanowił przenieść te koncepcje do otwartego oprogramowania i zaprezentował projekt Aspen — niezależną implementację na licencji Apache 2.0, dostępną w serwisie GitHub.
Równoległe gałęzie i brak przepakowywania
Aspen obsługuje standardowy protokół Gita przez HTTPS i SSH, choć operacje git push --force i --delete wymagają dodatkowej opcji -o force. Cała rewolucja dotyczy sposobu, w jaki serwer zarządza danymi. Zamiast jednej blokady na poziomie całego repozytorium, Aspen traktuje każdą gałąź niezależnie. Historia gałęzi jest przechowywana jako łańcuch wersji w bazie danych PostgreSQL (lub SQLite w środowisku lokalnym), a aktualizacja wskaźnika gałęzi polega na pojedynczej operacji atomowej compare-and-swap na jednym wierszu w bazie. Dzięki temu commity wysyłane do różnych gałęzi nigdy na siebie nie czekają.
Drugą kluczową zmianą jest obsługa plików z obiektami. Aspen nie rozpakowuje nadsyłanych paczek, lecz uzupełnia ewentualne brakujące zależności i odkłada je bezpośrednio do magazynu obiektowego, takiego jak Amazon S3 czy Azure Blob Storage. Podczas operacji fetch serwer nie marnuje zasobów procesora na ponowną kompresję historii, tylko strumieniuje gotowe paczki, które klient może pobierać również bezpośrednio z sieci CDN za pomocą podpisanych adresów URL. W tle działa mechanizm kompaktowania, który łączy małe paczki w większe poziomy — podobnie jak robią to bazy danych oparte na drzewach LSM.
Wydajność w testach
Według pomiarów opublikowanych przez Reason Machines pojedynczy 8-rdzeniowy serwer Aspen połączony z bazą PostgreSQL i standardowym magazynem S3 wytrzymał ciągłe obciążenie 567 operacji push na sekundę przez pięć minut bez żadnych błędów. Mediana opóźnienia wyniosła 208 milisekund, a 99. percentyl zamknął się w 314 milisekundach. Dla porównania, dedykowany serwer Origin rozwijany przez twórców edytora Cursor osiąga do 120 pushy na sekundę na S3 Standard i ponad 300 na wyspecjalizowanym magazynie S3 Express One Zone.
Oba wyniki uzyskano jednak w zupełnie innych warunkach: Aspen testowano na repozytorium git.git (około 4,5 tys. plików i 75 tys. commitów) przez adres przypisany do gałęzi, podczas gdy rezultaty Origina zmierzono na replikowanym klastrze obsługującym własne monorepo firmy Cursor. Reason Machines zwraca także uwagę, że w przypadku bardzo dużych monorepozytoriów koszt pojedynczej operacji rośnie, przez co osiągają one obecnie niższą przepustowość niż w opublikowanym teście.
Twórcy podkreślają, że Aspen znajduje się we wczesnej fazie pre-alpha. Narzędzie nie oferuje interfejsu webowego, a bezpośrednie scalanie zmian do głównej gałęzi (main) jest ograniczone do około 4 operacji na sekundę z powodu konieczności sekwencyjnego aplikowania commitów. Aspen ma też serwerową kolejkę scaleń, która pozwala łączyć wiele pull requestów w pojedynczej aktualizacji gałęzi main; jej wydajność nie została jeszcze opublikowana.
