Serverkapazität aus Arbeitslast und Engpässen ableiten

Die Arbeit beschreiben, die das System leisten soll

Eine Website erzeugt unterschiedliche Arbeit. Eine gespeicherte Informationsseite, eine Suche, eine Anmeldung und ein großer Import haben verschiedene technische Kosten. Die Zahl der monatlichen Besucher bildet diese Unterschiede nur grob ab. Für die Kapazitätsplanung brauchen Sie deshalb die wichtigsten Anfragearten und ihre zeitliche Verteilung. Welche Arbeit trifft gleichzeitig ein? Welche Aufgaben laufen im Hintergrund? Welche Funktionen müssen während dieser Aufgaben weiter nutzbar bleiben? Die Antworten verbinden das gewünschte Nutzerverhalten mit einem konkreten technischen Prüfbereich.

Beginnen Sie mit wenigen charakteristischen Abläufen aus Ihrer eigenen Anwendung. Ein Wissensportal kann überwiegend lesende Aufrufe besitzen, aber bei einer redaktionellen Veröffentlichung viele neue Bilder verarbeiten. Eine Buchungswebsite kann wenig Seitenaufrufe haben und trotzdem kritische gleichzeitige Schreibvorgänge ausführen. Eine Agenturinstallation kann nachts mehrere Kundenimporte bündeln. Diese Beispiele sind Planungsszenarien, keine gemessenen Eigenschaften eines bestimmten Tarifs. Sie zeigen, weshalb Kapazität pro Projekt und Betriebsphase betrachtet werden sollte. Ein pauschales „für viele Besucher geeignet“ lässt die entscheidende Arbeit offen.

Einen Engpass mit einer Beobachtung verbinden

Ein Engpass ist die Stelle, an der zusätzliche Arbeit nicht mehr im gewünschten Umfang verarbeitet wird. Er kann CPU, Speicher, Datenträger, Datenbank, Netzwerk oder ein konfiguriertes Parallelitätslimit betreffen. Auch ein langsamer externer Dienst kann lokale Prozesse lange binden. Suchen Sie deshalb nach der konkreten Wirkung: längere Antwortzeiten, wachsende Warteschlangen, Fehler oder verschobene Aufgaben. Eine einzelne hohe Kennzahl genügt nicht. Die Kapazitätsentscheidung soll eine beobachtete oder sauber begründete Einschränkung beheben, statt vorsorglich eine beliebige Ressource zu vergrößern.

Die Google-SRE-Darstellung zum Umgang mit Überlast liefert Hintergrund zum Verhältnis von Arbeit und Verarbeitungsspielraum. Für einen Websitebetreiber hilft besonders die Betrachtung der gesamten Kette. Wenn PHP lange auf eine Datenbankantwort wartet, kann die Belegung des Pools steigen, ohne dass PHP viel CPU verbraucht. Zusätzliche Prozesse vergrößern dann womöglich die Zahl wartender Datenbankverbindungen. Prüfen Sie die vermutete Ursache entlang der tatsächlichen Abhängigkeiten. Der Webserver-Requestweg erleichtert diese Zuordnung.

Parallelität und Dauer gemeinsam betrachten

Für eine erste gedankliche Näherung ist die gleichzeitig benötigte Verarbeitung abhängig davon, wie oft eine Arbeit ankommt und wie lange sie Ressourcen belegt. Wenn dieselbe Anfrage länger dauert, steigt bei unveränderter Ankunft auch die Überlappung. Das erklärt, weshalb eine kleine Laufzeitverschlechterung plötzlich Warteschlangen sichtbar machen kann. Die Näherung ist keine genaue Vorhersage für jede reale Last. Sie hilft aber, die richtige Frage zu stellen: Muss mehr gleichzeitig verarbeitet werden, oder sollte die einzelne Verarbeitung kürzer und effizienter werden?

Betrachten Sie außerdem Spitzen statt nur Tagesmittelwerte. Ein durchschnittlich ruhiger Auftritt kann bei einer Kampagne kurze dichte Ankunftsphasen erleben. Ein Import, der jede Nacht mit einer Sicherung zusammenfällt, kann ebenfalls einen Engpass erzeugen. Dokumentieren Sie typische und kritische Zeitfenster. Zahlen erhalten nur dann einen praktischen Wert, wenn der Messzeitraum und die gerade laufenden Aufgaben bekannt sind. Ein einzelner Mittelwert über eine Woche kann die kurze für Nutzer relevante Einschränkung ausblenden. Die Überwachung sollte deshalb die entscheidenden Zeiträume auflösen können.

PHP-Worker als begrenzten Pool einordnen

PHP-FPM besitzt Poolgrenzen für gleichzeitig verarbeitete Anfragen. Die offizielle Konfigurationsreferenz beschreibt unter anderem pm.max_children. Für die eigene Planung wird der tatsächliche Wert aus der Domainumgebung benötigt. Er sagt nicht allein, welche Besucherzahl möglich ist. Anfragen können unterschiedlich lange dauern und je nach Cacheweg PHP umgehen. Die sinnvolle Frage lautet deshalb, ob die vorhandene Parallelität die erwarteten dynamischen Aufgaben bei ihren tatsächlichen Laufzeiten verarbeiten kann. Beobachten Sie die zugehörige Warteschlange und den Nutzerzustand.

Eine Erhöhung der Poolgrenze benötigt freien Spielraum für die zusätzlich laufenden Prozesse und ihre Abhängigkeiten. Prüfen Sie den Speicherbedarf repräsentativer Prozesse während relevanter Aktionen. Eine bloße Multiplikation eines zufälligen Momentwerts bleibt eine grobe Orientierung. Gemeinsam genutzte Speicherbereiche und unterschiedliche Prozesszustände beeinflussen die Interpretation. Dokumentieren Sie deshalb das verwendete Messverfahren. Wenn Sie den zentralen Bestand eines geteilten Servers nicht sehen dürfen, kann nur die Administration die Gesamtreserve beurteilen. Der PHP-FPM-Ratgeber behandelt die gezielte Fehlerdiagnose im Pool.

Speicher als Systemspielraum prüfen

Arbeitsspeicher wird nicht nur von PHP genutzt. Datenbank, Webserver, Betriebssystem und Caches benötigen ebenfalls Platz. Die Linux-Kerneldokumentation zu proc erläutert die verfügbaren Systeminformationen. Für eine Entscheidung betrachten Sie den verfügbaren Spielraum im Zusammenhang mit Prozessverhalten und möglichen Speicherengpässen. Die Anzeige „viel Speicher belegt“ ist ohne Interpretation wenig aussagekräftig, weil der Kernel Speicher auch sinnvoll für Zwischenspeicherung verwendet. Eine Ressourcenplanung darf solche Nutzung nicht pauschal als Defekt behandeln.

Untersuchen Sie, ob eine bestimmte Aufgabe den Prozessbedarf außergewöhnlich erhöht. Bildverarbeitung, große Exporte oder ungebremste Datenabfragen können andere Anforderungen besitzen als öffentliche Leseaufrufe. Es kann sinnvoller sein, diese Aufgaben anders zu organisieren, statt jedes normale Requestlimit entsprechend ihrer Spitze zu erhöhen. Ein Limit schützt ebenfalls vor unkontrolliertem Verbrauch. Wenn Sie es verändern, benennen Sie die Aufgabe und die Abnahme. Der Updateablauf bietet dafür den kontrollierten Rahmen mit Ausgangszustand und Rückweg.

Datenbank und Datenträger in die Kette aufnehmen

Eine Anwendung kann langsam wirken, weil ihre Abfragen mehr Daten durchsuchen oder auf Sperren warten. Zusätzliche Webserverkapazität behebt diese Arbeit nicht automatisch. Prüfen Sie bekannte problematische Aktionen und deren zeitgebundene Datenbankspur, soweit die Berechtigungen und Werkzeuge dies erlauben. Vermeiden Sie riskante globale Diagnoseänderungen im Kundenscope. Ein gezielter Bericht an die zuständige Administration enthält Handlung, Zeitraum und beobachtete Verzögerung. Bei Eigenentwicklungen kann eine Prüfung der Abfragen oder des Datenmodells erforderlich werden. Die Arbeitsteilung muss dafür klar sein.

Auch Datenträgerkapazität besitzt mehrere Dimensionen. Freier Platz ist wichtig, beantwortet aber nicht die Frage nach gleichzeitigen Zugriffen und deren Verzögerung. Eine Sicherung kann viele Daten lesen, während ein Import neue Daten schreibt. Wenn beide Wege konkurrieren, kann ein anderer Zeitplan helfen. Prüfen Sie außerdem Aufbewahrung und Wachstum von Uploads, Logs und Archiven. Ein dauerhaft wachsender Bestand verdient eine Prognose mit echten Beobachtungen. Eine statische Tarifzahl allein zeigt nicht, wann der verfügbare Platz bei der aktuellen Betriebsweise knapp werden könnte.

Cachewirkung mit ihren Grenzen betrachten

Ein wirksamer Cache kann bestimmte Arbeit sparen. Er hilft jedoch nur für Anfragen, die tatsächlich über diesen Weg beantwortet werden dürfen. Anmeldung, individuelle Inhalte und schreibende Aktionen benötigen häufig andere Pfade. Prüfen Sie deshalb die reale Trefferlage für die relevanten Anfragearten. Ein Cacheplugin als installierter Bestandteil beweist keinen aktiven Servercache. Der LiteSpeed-Betriebsratgeber zeigt die notwendigen Bestandsfragen. Eine Kapazitätsplanung sollte einen kalten Zustand ebenfalls berücksichtigen, etwa nach einer größeren Invalidierung oder einer Wiederherstellung.

Vergleichen Sie den erwarteten Normalzustand mit wichtigen Ausnahmezuständen. Nach einer Veröffentlichung können mehrere Seiten neu aufgebaut werden müssen. Ein Browserbesuch im Warmzustand erfasst diese Arbeit nicht. Für einen kontrollierten Test dokumentieren Sie deshalb Cachezustand und Zielpfade. Die daraus beobachteten Zeiten sind keine allgemeinen Performanceversprechen. Sie gelten für das konkrete Verfahren und den Bestand. Wenn der Test mit wenigen Seiten erfolgt, wird diese Grenze genannt. So bleibt er als technische Entscheidungshilfe nützlich, ohne einen repräsentativen Lastnachweis vorzutäuschen.

Eine Lastprüfung sicher begrenzen

Ein Belastungstest verändert die Arbeit auf dem Zielsystem und kann echte Nutzer beeinträchtigen. Verwenden Sie eine geeignete Testumgebung oder einen abgestimmten begrenzten Prüfrahmen. Beschreiben Sie Anfragen, Dauer, Parallelität und Abbruchkriterien vorher. Ein Test auf einer fremden oder geteilten Infrastruktur benötigt die passende Zuständigkeit. Der Betreiberauftrag für eine einzelne Website ist kein allgemeiner Auftrag, andere Kunden durch Last zu beeinflussen. Lesende Bestandsprüfungen und vorhandene Messdaten können häufig bereits eine erste Entscheidung vorbereiten, bevor ein künstlicher Lastlauf erforderlich wird.

Wählen Sie ein realistisches Anfragegemisch. Tausende Abrufe derselben gecachten Startseite können eine bestimmte Auslieferungsspur prüfen, bilden aber keinen Redaktionsspeicherweg oder eine Produktsuche ab. Der Test muss die beabsichtigte Aussage benennen. Wenn vor allem dynamische Funktionen relevant sind, werden diese in geeigneter kontrollierter Form geprüft. Erfassen Sie neben Antwortzeit auch Fehler und Ressourcenverhalten. Eine schnelle Antwort auf Fehlerseiten wäre kein positiver Anwendungstest. Die Abnahme benötigt erwarteten Inhalt und gegebenenfalls einen kontrollierten Datenzustand.

Aus dem Befund eine Hostingentscheidung ableiten

Erst jetzt lässt sich beurteilen, ob eine Tarifänderung die relevante Grenze beeinflusst. Welche Ressource wächst tatsächlich? Welche Limits bleiben bestehen? Sind eigene Einstellungen möglich oder verwaltet der Anbieter die zentralen Dienste? Ein größeres Paket kann mehr Speicher liefern und trotzdem denselben benötigten technischen Zugriff nicht enthalten. Prüfen Sie deshalb das aktuelle offizielle Angebot und offene Anforderungen. Die Hostingzuständigkeiten helfen bei dieser Einordnung. Eine Produktvorstellung kann Fragen strukturieren, ersetzt aber keine verbindliche Zusage zu Ihrer konkreten Anwendung.

Eine mögliche Alternative ist die Arbeitsorganisation. Importe können außerhalb redaktioneller Spitzen laufen; Hintergrundaufgaben können kleiner portioniert werden; unnötige Abfragen können entfallen. Solche Maßnahmen verdienen denselben Nachweis wie zusätzliche Ressourcen. Halten Sie den Ausgangsbefund, die Änderung und den erneuten Test fest. Ein still geänderter Zeitplan kann später beim Restore oder bei einer neuen Kampagne wieder kollidieren. Verknüpfen Sie die Entscheidung deshalb mit dem Betriebsblatt. Kapazität ist eine Eigenschaft von Bestand, Konfiguration und Arbeitsweise zusammen.

Reserve für Änderungen und Wiederherstellung einplanen

Ein System sollte nicht ausschließlich für den ruhigsten Normalbetrieb geplant werden. Sicherungen, Updates und Restoreübungen benötigen ebenfalls Ressourcen. Bei einer Wiederherstellung kann das Ziel parallel zum laufenden Original bestehen. Prüfen Sie, ob Platz und Verarbeitungsspielraum dafür vorhanden sind. Der Restore-Ratgeber und der RPO/RTO-Plan verbinden diese Reserve mit dem Wiederanlauf. Ein technisch mögliches Archiv kann praktisch schwer nutzbar werden, wenn weder eine geeignete Zielumgebung noch ausreichender temporärer Speicher vorbereitet sind.

Erfassen Sie beobachtetes Wachstum mit Zeitraum und Ursache. Neue Medien, längere Logaufbewahrung oder ein geändertes Datenmodell können den Bestand verändern. Eine Prognose wird als Prognose gekennzeichnet und regelmäßig gegen echte Daten geprüft. Erfinden Sie keine künftigen Besucherzahlen oder garantierten Reserven. Für eine Entscheidung kann schon ein plausibler geplanter Vorgang dienen, etwa ein dokumentierter größerer Import. Dann werden dessen Voraussetzungen genannt und später abgenommen. So bleibt der Kapazitätsplan an tatsächlichen Betriebsentscheidungen orientiert.

Ein kompaktes Kapazitätsblatt pflegen

• Relevante Anfragearten und Hintergrundaufgaben mit Zeitfenstern erfassen.
• Nutzerwirkung und vermutete Ressourcengrenze durch Beobachtungen verbinden.
• PHP-Parallelität, Speicher, Datenbank und I/O gemeinsam betrachten.
• Cachezustand und Ausnahmephasen bei Vergleichen ausdrücklich nennen.
• Änderungen mit Ausgangszustand, Rückweg und erneuter Prüfung dokumentieren.
• Tarifgrenzen, zentrale Zuständigkeiten und offene Messungen sichtbar lassen.

Das Blatt wird nach größeren Änderungen aktualisiert. Es soll eine konkrete Entscheidung erklären können: Welche Arbeit hat das Problem ausgelöst, welche Grenze wurde beobachtet und welche Maßnahme hat sie nachweisbar verbessert? Wenn diese drei Aussagen vorhanden sind, wird ein Hostingvergleich wesentlich präziser. Der Betreiber kann mehr Ressourcen, effizientere Verarbeitung und einen angepassten Zeitplan anhand ihrer tatsächlichen Wirkung beurteilen, statt eine allgemeine Größenempfehlung als vermeintlich gesicherte Lösung zu übernehmen.