Kapazitätsschätzer

Wie viele Server brauchen Sie wirklich? Beantworten Sie es mit Arithmetik statt mit Bauchgefühl: Geben Sie dem Schätzer Ihre Anfragenrate, die CPU-Zeit, die jede Anfrage verbrennt, und die Antwortzeit, die Nutzer sehen, und er gibt zurück, wie viele Kerne der Traffic beschäftigt hält, die ganzen Server, die bereitzustellen sind — mit Ihrer Redundanzpolitik angewendet —, die Parallelität, die Ihre Verbindungspools überleben müssen, und wie derselbe Dienst bei zwei-, fünf- und zehnfachem Traffic aussieht.

Die Formeln, in einfachen Worten

Kerne. Multiplizieren Sie die Anfragenrate mit den CPU-Sekunden, die jede Anfrage verbraucht: So viele Kerne hält der Traffic bei 100 % beschäftigt. Dann teilen Sie durch Ihre Zielauslastung — bei 70 % zählt jeder bereitgestellte Kern nur als 0,7 eines Plankerns, und die anderen 0,3 sind der Spielraum, der die Warteschlangen kurz hält, wenn der Traffic schwankt. Benötigte Kerne = Anfragen/s × CPU-Sekunden pro Anfrage ÷ Zielauslastung.

Server. Teilen Sie die Kerne durch die Kerne pro Server und runden Sie nach oben — es gibt kein 0,4 eines Servers, und Abrunden ist der Weg, wie ein Plan, der im Durchschnitt funktioniert, an der Spitze scheitert. Die Redundanz wird danach angewendet: N+1 fügt der gerundeten Anzahl einen Ersatzserver hinzu; 2N verdoppelt die gesamte Flotte. Die Parallelität ist eine separate Zahl aus Little's law: Anfragen in Bearbeitung = Anfragen/s × Antwortzeit in Sekunden. Sie bestimmt die Größe von Thread-Pools, Datenbankverbindungen und Dateideskriptoren — die Grenzen, die Dienste tatsächlich erreichen, während ihre CPUs noch faulenzen. Der Ausgang ist, wenn Sie eine Antwortgröße angeben, Anfragen/s × Größe × 8, die Bits, aus denen Ihre Netzwerkrechnung besteht. Der Begleitartikel, wie viele Server Sie wirklich brauchen, erklärt, woher jede Eingabe kommt und warum die Benchmarks der Anbieter mit all dem nicht übereinstimmen.

Planungsgeschwister: Der SLA-Fehlerbudget-Rechner verwandelt das Verfügbarkeitsziel, das diese Kapazität verteidigt, in Minuten, und der Rechner für die Backup-Aufbewahrung dimensioniert die Speicherseite desselben Systems.

Häufig gestellte Fragen

Warum für 70 % Auslastung planen statt für 100 %?

Weil Warteschlangen vor der Sättigung explodieren, nicht an ihr. Eine CPU, die im Durchschnitt zu 95 % beschäftigt ist, ist eine CPU, deren Warteschlange bei jeder Traffic-Schwankung grenzenlos wächst — und Traffic schwankt immer. Das Auslastungsziel ist der Spielraum, der Spitzen, Deployments, Wiederholungen und eine langsame Abhängigkeit absorbiert. Siebzig Prozent sind der Branchenstandard für latenzempfindliche Dienste; Stapelarbeiter, die Verzögerungen tolerieren, können heißer laufen, und alles Nutzerzugewandte und Spitzenbehaftete sollte kühler laufen.

Was ist der Unterschied zwischen Kernen und Anfragen in Bearbeitung?

Sie beantworten verschiedene Fragen. Kerne kommen aus der CPU-Servicezeit: wie viel Prozessor jede Anfrage verbraucht. Anfragen in Bearbeitung kommen aus Little's law: Rate multipliziert mit Antwortzeit, und sie messen Parallelität — Verbindungen, Threads, offen gehaltenen Speicher —, nicht Prozessorlast. Ein Dienst mit langsamen nachgelagerten Aufrufen kann 500 Anfragen in Bearbeitung halten, während er zwei Kerne nutzt, und ihm geht der Verbindungspool aus, lange bevor ihm die CPU ausgeht. Dimensionieren Sie beides, sonst wird das, was Sie ignoriert haben, zum Ausfall.

Mein Lasttest sagt, ein Server schafft 2.000 Anfragen pro Sekunde. Warum widerspricht dieser Schätzer?

Lasttests messen üblicherweise einen warmen, stabilen, cacheheißen Dienst, der eine einzige Anfragenform von einem großzügigen Client beantwortet. Die Produktion fügt Kaltstarts, TLS-Handshakes, Wiederholungen, einen langen Schwanz langsamer Anfragen, laute Nachbarn und das Deployment hinzu, das die Kapazität für zehn Minuten halbiert. Der Schätzer ist absichtlich konservativ — durchschnittliche CPU-Zeit, eine Auslastungsobergrenze, ganze Server, Redundanz hinzugefügt. Betrachten Sie den Lasttest als die Decke des Möglichen und diese Zahl als den Boden dessen, was bereitzustellen ist; die Wahrheit für die Planung ist der Boden.

Wogegen schützt N+1 tatsächlich?

Gegen einen Ausfall: einen toten Host, ein schlechtes Deployment, das aus der Rotation gezogen wird, ein Ereignis in einer Verfügbarkeitszone, das eine einzelne Instanz mitnimmt. Mit N+1 erfüllen die verbleibenden N Server das Ziel immer noch — das ist der Sinn davon, N zuerst aus dem Traffic zu dimensionieren und den Ersatz danach hinzuzufügen. 2N ist ein anderes Versprechen: zwei vollständige Kopien, üblicherweise über Regionen hinweg, für Dienste, die den Verlust einer ganzen Kopie überleben müssen. Es verdoppelt die Rechnung, also wird es für die Dienste gekauft, deren Abwesenheit in Schlagzeilen gemessen wird.

Wie bekomme ich meine CPU-Servicezeit pro Anfrage?

Messen Sie sie, raten Sie sie nicht. Bei einem laufenden Dienst: die gesamten in einem Fenster verbrauchten CPU-Sekunden, geteilt durch die im selben Fenster bedienten Anfragen. Werkzeuge zur Anwendungsleistungsüberwachung berichten sie direkt als CPU pro Anfrage; unter Linux können Sie sie aus der Prozess-CPU-Zeit in /proc oder aus Ihren Container-Metriken ableiten. Verwenden Sie die Zahl aus Ihrer geschäftigsten realistischen Stunde, nicht den Tagesdurchschnitt — Kapazität, die aus Durchschnitten geplant wurde, scheitert genau an der Spitze, für die sie gekauft wurde.