Ein CI-Runner kann minutenlang alle verfügbaren CPU-Ressourcen beanspruchen und danach fast untätig sein. Deshalb sagt die Zahl der vCPUs wenig darüber aus, ob Ihre Builds schneller werden. Entscheidend ist, welcher Teil der Pipeline Zeit verbraucht und wie viele Jobs gleichzeitig laufen müssen.
Einen repräsentativen Build festlegen
Wählen Sie einen typischen Commit und protokollieren Sie getrennt: Abhängigkeiten herunterladen, kompilieren, Tests ausführen und Artefakte hochladen. Vergleichen Sie mehrere Durchläufe mit kaltem und warmem Cache. Ändern Sie zwischen zwei Messungen nur eine Variable; sonst bleibt unklar, ob die CPU oder der Cache den Unterschied verursacht hat.
Hetzners deutsche Cloud-Seite unterscheidet geteilte und dedizierte CPU-Angebote. Auch netcup trennt seine Serverklassen und Ressourcen. Diese Produktseiten helfen, Angebotsbegriffe einzuordnen; sie belegen keine garantierte Build-Leistung eines anderen Anbieters. Fragen Sie bei jedem Angebot ausdrücklich nach dem Zuteilungsmodell, wenn konstante CPU-Leistung kaufentscheidend ist.
Parallelität hat einen Speicherpreis
Angenommen, ein gemessener Testjob benötigt in der Spitze 1,5 GB RAM. Vier gleichzeitig gestartete Jobs benötigen bereits ungefähr 6 GB allein für diese Prozesse. Betriebssystem, Runner und Dateicache kommen hinzu. Das Beispiel ist keine Paketempfehlung: Messen Sie insbesondere Compiler und Tests, die selbst weitere Prozesse starten.
Starten Sie mit begrenzter Parallelität. Steigt die Gesamtdurchsatzrate kaum, während einzelne Builds deutlich länger dauern, erhöhen Sie nicht blind die Jobzahl. Prüfen Sie Speicherdruck, CPU-Auslastung und Wartezeiten auf Datenträger oder externe Dienste. Ein langsamer Paketserver wird durch zusätzliche Kerne auf dem Runner nicht schneller.
Temporäre Daten einplanen
Arbeitsverzeichnisse, Container-Abbilder und Artefakte können wesentlich größer sein als das Repository. Legen Sie Aufbewahrungsfristen fest und bereinigen Sie nur eindeutig temporäre Daten. Prüfen Sie, ob ein abgebrochener Build Dateien hinterlässt. Ein voller Datenträger kann auch den nächsten, eigentlich kleinen Job verhindern.
Behandeln Sie fremde Pull Requests als nicht vertrauenswürdigen Code. Nutzen Sie getrennte Ausführungsumgebungen ohne Produktionszugänge; Geheimnisse gehören nicht in Build-Protokolle. Prüfen Sie nach einem Neustart, ob der Runner wieder startet und unterbrochene Jobs eindeutig als fehlgeschlagen erkannt werden.
Mit den Messwerten können Sie VDS-Pläne und die vorhandene Ryzen-VDS-Produktfamilie gezielt vergleichen. Eine CPU-Modellbezeichnung ersetzt den eigenen Test nicht. Prüfen Sie aktuelle Konfiguration, Verfügbarkeit und Leistungsumfang; ein fertig eingerichteter CI-Dienst oder garantierte Build-Zeiten werden damit nicht zugesagt.