Platz für alle, die gleichzeitig ankommen

Unser Webdienst läuft auf Cloud Run. Zwei Einstellungen entscheiden, wie viel er gleichzeitig bedienen kann: wie viele Anfragen ein einzelner Container parallel verarbeitet und wie viele Container nebeneinander laufen dürfen. Multipliziert ergibt das die Obergrenze der ganzen Website. Unsere lag bei 4 mal 3: zwölf Anfragen im selben Moment.

Zwölf klingt großzügig, bis man zählt, was ein Besuch kostet. Jede Seite unserer Website wird auf dem Server gerendert, und eine Seite voller Navigationslinks lädt mehrere der dahinterliegenden Seiten schon vorab, damit sie sich beim Klick sofort öffnen. Ein einziger Seitenaufruf fächert sich in 8 bis 16 Anfragen auf. Zwei oder drei Personen, die in derselben Sekunde eine Seite öffnen, können das ganze Kontingent ausschöpfen, und ist es voll, weist die Plattform die nächste Anfrage sofort ab, statt sie einzureihen.

Wir wollten, dass kein Besucher je an diese Grenze stößt.

Wir haben drei Zahlen geändert, jede aus einem klaren Grund:

• Parallelität von 4 auf 20: der Hebel, der nichts kostet, weil er die Container nutzt, die ohnehin laufen
• höchstens 10 statt 3 Container: genug für eine echte Spitze
• Zeitlimit einer Anfrage von einer Stunde auf zwei Minuten: Nichts im Webteil braucht länger, denn Renderings laufen als eigene Jobs und unser MCP-Endpunkt begrenzt sich selbst auf 60 Sekunden, und eine hängende Anfrage sollte nie eine Stunde lang einen Platz belegen

Die Obergrenze stieg von 12 gleichzeitigen Anfragen auf 200. Was man zahlt, wenn die Website ruhig ist, ist die Mindestzahl an Containern, und die blieb gleich. Mehr Spielraum, dieselben Kosten im Leerlauf.

In solchen Einstellungen steckt eine leise Falle. Unser Release-Schritt übergibt sie bei jedem Deployment an die Plattform, ein von Hand am laufenden Dienst geänderter Wert wird also vom nächsten Release wieder auf den alten gesetzt.

Deshalb stehen die neuen Zahlen im Release-Ablauf selbst, neben dem Code, geprüft wie Code und mit jeder Version angewendet. Eine Kapazitätseinstellung, die das Release nicht kennt, ist ein Versuch, keine Lösung. Seit diesem Tag trägt jedes Release die echte Kapazität der Website mit sich.

Mehr Container verändern noch etwas anderes: die Last auf der Datenbank. Jeder Container hält einen kleinen Vorrat offener Datenbankverbindungen. Die Standardgröße dieses Vorrats hängt von der Maschine ab, bei uns fünf pro Container. Bei drei Containern waren das 15. Bei zehn wären es 50, und unsere Datenbank nimmt 25 an.

Also legen wir die Größe des Vorrats ausdrücklich fest, statt sie einer Rechnung zu überlassen, die niemand macht. Zwei Verbindungen pro Container mal zehn Container ergeben zwanzig, und das lässt Platz für die Render-Jobs, die Schemaprüfung, die jeder Container beim Start macht, und für einen Menschen, der eine Datenbankkonsole öffnen muss. Die Grenze wird im Code gesetzt, nicht in die gespeicherte Verbindungszeichenkette geschrieben, denn Zugangsdaten und Vorratsgröße sind verschiedene Dinge: Das eine ist ein Geheimnis, das andere eine Eigenschaft des Programms, das sie nutzt. Ein Konfigurationswert kann sie weiterhin überschreiben.

Wir haben das Ergebnis am echten Dienst geprüft und 40 Anfragen genau gleichzeitig geschickt. Alle 40 wurden beantwortet, mit Seiten in 180 bis 340 Millisekunden. Das ist auf einen Schlag mehr als das Dreifache der alten Obergrenze, mit Luft nach oben.

Außerdem haben wir aufgeschrieben, was wir gelernt haben, neben dem Code und in unseren Projektnotizen:

1. 1jede Kapazitätszahl ist ein Produkt: Parallelität mal Container ist die Obergrenze der Website, Vorratsgröße mal Container ist die Last der Datenbank
2. 2ändere einen Faktor und rechne jedes Produkt neu, in dem er vorkommt
3. 3auf einer Website, deren Seiten alle auf dem Server gerendert werden, vervielfacht das Vorladen von Links den Traffic, und wer ein Linkmenü hinzufügt, sollte wissen, was es kostet

Weitere Kapitel über die Plattform hinter den Filmen findest du im Blog.