Ein Managed Server wird nicht allein nach der Anzahl der WordPress-Websites ausgewählt. Entscheidend ist, welche Arbeit diese Websites gleichzeitig erzeugen und welche Reserven für Änderungen, Sicherungen und Wachstum gebraucht werden. Eine dynamische Anwendung mit individuellen Nutzerkonten kann mehr Ressourcen benötigen als viele kleine Informationsseiten.
Die Tabelle lässt sich seitlich verschieben.
| Bereich | Was Sie erfassen | Entscheidung daraus |
|---|---|---|
| CPU | Dynamische Anfragen, Importe und Lastspitzen | Mehr Parallelität oder eine aufwendige Funktion gezielt prüfen |
| RAM | Gleichzeitige PHP-Prozesse, Datenbank und weitere Dienste | Gesamtbedarf von einzelnen Prozesslimits unterscheiden |
| Datenträger | Dateien, Datenbank, Logs, Testkopien und Wachstum | Platz für Alltag und Zwischenstände einplanen |
| Ein- und Ausgabe | Wartezeiten bei Abfragen, Archiven und Sicherungen | Zeitpläne entzerren oder den belegten Engpass untersuchen |
| Cache | Cachetreffer und nicht cachebare Seitentypen | Anonyme und personalisierte Last getrennt bewerten |
| Hintergrundjobs | Zeitplan, Laufdauer und Überlappungen | Doppelte oder gleichzeitig startende Arbeit vermeiden |
- Projekte inventarisieren
- Dynamische Last messen
- CPU und RAM aufteilen
- Speicher und Backups planen
- Reserve prüfen
Dimensionierung heißt, eine konkrete Last tragfähig zu bedienen
Die richtige Dimensionierung verbindet deshalb einen Überblick über die Projekte mit Messwerten aus repräsentativen Betriebsphasen.
Beginnen Sie mit einer nüchternen Bestandsaufnahme. Welche Websites sind aktiv, welche werden bald ergänzt und welche laufen nur als Testkopie? Welche Funktionen erzeugen Datenbankarbeit oder Hintergrundjobs? Welche Zeiträume sind geschäftlich wichtig? Aus diesen Angaben entsteht ein Lastprofil. Es hilft dabei, CPU, Arbeitsspeicher und Speicherplatz getrennt zu betrachten. Eine pauschale Empfehlung wie ein bestimmter Tarif für jede Besucherzahl bleibt dagegen zu ungenau. Dieser Ratgeber zeigt, wie Sie Anforderungen messbar machen und daraus eine nachvollziehbare Auswahl ableiten.
Welche Projekte erzeugen welche Arbeit?
Legen Sie für jedes Projekt einen kurzen Eintrag an. Erfassen Sie die Betriebsart, den genutzten Speicher, die Datenbankgröße, regelmäßig laufende Aufgaben und den Wartungsrhythmus. Notieren Sie, ob die meisten Seiten öffentlich gleich sind oder ob individuelle Antworten entstehen. Eine Suchfunktion, eine Buchung oder ein Warenkorb beeinflussen das Profil anders als eine einfache Artikelseite. Auch die Häufigkeit neuer Inhalte ist relevant.
Ergänzen Sie die erwarteten nächsten Schritte: zusätzliche Sprache, mehr Medien, größerer Produktbestand oder neue Kundenwebsites. Unterscheiden Sie bestätigte Pläne von bloßen Möglichkeiten. Die Inventarliste soll den Bedarf erklären und keine künstlich große Reserve erzeugen. Für bestehende Projekte werden aktuelle Werte aus der Hostingverwaltung und aus gezielten Messungen eingetragen. Bei neuen Projekten helfen repräsentative Teststände. Ein fehlender Wert bleibt zunächst offen und wird vor einer endgültigen Empfehlung geprüft. So entsteht eine belastbare Grundlage, die sich später weiterführen lässt.
CPU: dynamische Arbeit und Parallelität betrachten
CPU wird unter anderem gebraucht, wenn PHP Seiten erzeugt, Plugins Daten verarbeiten oder die Datenbank komplexe Abfragen ausführt. Mehr virtuelle CPUs können mehrere Aufgaben parallel ermöglichen, wenn die Anwendung und Konfiguration dazu passen. Eine einzelne langsame Anfrage wird jedoch nicht automatisch proportional schneller, nur weil mehr Recheneinheiten bereitstehen. Ihre Laufzeit kann von einem seriellen Verarbeitungsschritt oder einer externen Verbindung abhängen.
Prüfen Sie daher sowohl die gesamte CPU-Auslastung als auch die Dauer typischer dynamischer Anfragen. Beobachten Sie problematische Zeiträume und geplante Jobs. Fragen Sie beim Anbieter nach dem Ressourcenmodell der virtuellen CPUs, statt sie ungeprüft mit exklusiven physischen Kernen gleichzusetzen. Für einen Vergleich sind tatsächlich gemessene Antwortzeiten und das Verhalten bei gleichzeitiger Last entscheidend. Auch die beworbene Taktfrequenz allein erlaubt keinen verlässlichen Leistungsvergleich unterschiedlicher Umgebungen. Die Kombination aus Anwendung, Serverplattform und Konfiguration muss betrachtet werden.
RAM: Dienste, Prozesse und Reserven zusammen planen
RAM wird vom Betriebssystem, Webserver, PHP, Datenbank und gegebenenfalls weiteren Diensten genutzt. Ein Teil kann für Caches sinnvoll eingesetzt werden. Zusätzlich benötigen gleichzeitige PHP-Prozesse ihren jeweiligen Arbeitsspeicher. Ein hoher Wert im Serverangebot ist deshalb keine einzelne frei verfügbare Tasche für WordPress. Sie müssen abschätzen, welche Komponenten gleichzeitig Speicher brauchen und wie sich Spitzen auswirken.
Als Rechenbeispiel, nicht als Tarifempfehlung: Wenn ein repräsentativer PHP-Prozess im Mittel 120 Megabyte belegt und 20 solche Prozesse gleichzeitig laufen, ergibt das rund 2,4 Gigabyte allein für diesen Teil. Datenbank, Betriebssystem und weitere Dienste kommen hinzu. Der tatsächliche Bedarf kann stark abweichen und muss gemessen werden. Beachten Sie insbesondere aufwendige Importe oder Bildverarbeitung. Prüfen Sie, ob Speicherdruck, Auslagerung oder abgebrochene Prozesse auftreten. Ein Server mit ausreichend Gesamt-RAM kann trotzdem Fehler zeigen, wenn eine einzelne Anwendung eine unpassend gesetzte Prozessgrenze erreicht.
PHP-Speicherlimit und Gesamt-RAM unterscheiden
Untersuchen Sie eine konkrete Fehlermeldung deshalb gezielt. Tritt sie beim Bilderupload, beim Import oder bei normalen Seitenaufrufen auf? Wie groß sind die verarbeiteten Dateien und welche Erweiterung arbeitet dabei? Die bloße Erhöhung aller Grenzen kann eine ineffiziente Anwendung verdecken. Eine sinnvolle Anpassung wird mit Messung und Funktionsprüfung verbunden. Stimmen Sie serverbezogene Änderungen mit dem zuständigen Anbieter ab. Im WordPress-Leitfaden zur Geschwindigkeit wird erläutert, wie technische Symptome und Browserprobleme auseinandergehalten werden.
Gleichzeitige Anfragen realistisch erfassen
Eine tägliche Besucherzahl sagt wenig darüber aus, wie viele dynamische Anfragen im selben Moment verarbeitet werden müssen. Verteilte Zugriffe können eine Umgebung kaum beanspruchen. Eine kurze Kampagnenspitze oder ein automatisierter Zugriff kann dagegen Warteschlangen erzeugen. Außerdem besteht ein Seitenbesuch aus mehreren Anfragen, von denen viele statisch oder zwischengespeichert sind. Nicht jeder Aufruf braucht dieselbe PHP-Arbeit.
Sammeln Sie deshalb Daten zu dynamischer Gleichzeitigkeit, Prozessauslastung und Antwortdauer. Testen Sie unterschiedliche Seitentypen und berücksichtigen Sie eingeloggte Nutzer. Prüfen Sie auch, ob langsame externe Dienste Prozesse länger binden. Wenn eine Anfrage mehrere Sekunden wartet, belegt sie Ressourcen länger als eine rasch abgeschlossene Antwort. Eine geringe durchschnittliche CPU-Auslastung schließt deshalb ein Problem mit belegten Prozessen nicht aus. Dimensionierung bedeutet, diese Zusammenhänge zu erkennen und die passenden Grenzen zu wählen, statt allein eine maximale Besucherzahl aus einer Tabelle abzulesen.
Cachetreffer und nicht cachebare Bereiche trennen
Bei vielen WordPress-Websites kann ein Seitencache einen erheblichen Teil wiederholter Arbeit vermeiden. Seine Wirkung hängt jedoch davon ab, welche Antworten tatsächlich gespeichert und wiederverwendet werden. Ein schneller Startseitenaufruf belegt nicht, dass Suchergebnisse, Benutzerkonten und andere dynamische Bereiche genauso gut bedient werden. Für die Kapazitätsplanung werden deshalb anonyme Cachetreffer und nicht cachebare Anfragen separat betrachtet.
Prüfen Sie für wichtige URLs den Cachezustand und die Antwortzeit. Testen Sie nach einer Änderung auch den ersten ungecacheten Zugriff. Wenn ein Crawler viele Seiten vorwärmt, entsteht dafür selbst Serverarbeit, die geplant werden muss. Mehr Cachefunktionen sind nicht automatisch besser. Falsch gewählte Regeln können persönliche Inhalte oder veraltete Antworten zeigen. Bei LiteSpeed sind Serverkonfiguration und Plugin gemeinsam zu prüfen. Eine sichere lokale Konfiguration kann ausreichen; kostenpflichtige Optimierungsdienste sollten nicht stillschweigend zur Voraussetzung einer dimensionierten Websiteumgebung gemacht werden.
Datenbankgröße und Datenbanklast getrennt betrachten
Eine große Datenbank ist nicht zwangsläufig langsam. Entscheidend sind unter anderem Struktur, Abfragen, Zugriffsmuster und verfügbare Ressourcen. Eine kleine Datenbank mit ineffizienten Abfragen kann viel CPU benötigen. Viele ungenutzte Protokolldaten können dagegen vor allem Speicher und Sicherungsdauer erhöhen. Für die Planung sollten Größe und Verarbeitung deshalb getrennt erfasst werden.
Untersuchen Sie auffällige Funktionen wie Filter, Suche oder regelmäßige Synchronisationen. Lassen Sie lange Abfragen fachlich prüfen, bevor Tabellen verändert oder Daten gelöscht werden. Ein Backup und ein Rückweg gehören zu solchen Anpassungen. Erfassen Sie außerdem, welche Daten wirklich gebraucht werden und welche Aufbewahrungsregeln gelten. Eine pauschale Optimierungsfunktion kann keine individuelle Prüfung ersetzen. Wenn nachweislich eine einzelne Erweiterung einen Engpass erzeugt, ist deren Anpassung häufig wirkungsvoller als ein größerer Server. Die höhere Tarifstufe sollte für einen belegten Gesamtbedarf gewählt werden und nicht als Ersatz für jede Ursachenanalyse.
Speicher: Wachstum und Zwischenstände einrechnen
Zum benötigten Datenträger gehören WordPress-Dateien, Medien, Datenbanken, Logs und weitere technische Daten. Hinzu kommen Testkopien, temporäre Archive und gegebenenfalls lokale Sicherungen. Ein Relaunch kann zeitweise zwei umfangreiche Projektstände benötigen. Der aktuell sichtbare Medienordner allein ist deshalb keine vollständige Speicherplanung. Auch die Zahl der Dateien und das Wachstum einzelner Bereiche können relevant sein.
Als Beispiel: Eine Website nutzt 35 Gigabyte für Medien und Anwendung, die Datenbank weitere 3 Gigabyte. Eine gleich große Testkopie bringt den Projektbedarf bereits in eine andere Größenordnung. Werden zusätzlich lokale Archive aufbewahrt, steigt die Belegung erneut. Dieses Beispiel ist eine Rechenhilfe, keine Zusage zu Kompressionsraten. Prüfen Sie die tatsächlichen Werte und halten Sie technische Reserve für den laufenden Betrieb frei. Eine vollständig gefüllte Partition kann mehrere Dienste zugleich beeinträchtigen. Backupspeicher aus dem Tarif darf außerdem nicht einfach zum produktiven Serverdatenträger addiert werden.
Ein- und Ausgabe unter Last beobachten
Schnelle Datenträger können beim Lesen und Schreiben helfen, doch die Interfacebezeichnung allein beschreibt nicht das gesamte Verhalten. Datenbankzugriffe, Backups und viele kleine Dateizugriffe können eine Umgebung unterschiedlich beanspruchen. Wichtig sind die tatsächliche Verarbeitung, Wartezeiten und mögliche Grenzen für das einzelne Konto. CPU kann dabei teilweise frei bleiben, obwohl Anfragen auf Ein- oder Ausgabe warten.
Beobachten Sie die auffälligen Zeiträume gemeinsam mit dem zuständigen Betriebsteam. Prüfen Sie, ob mehrere Sicherungen gleichzeitig laufen oder große Archive erzeugt werden. Ordnen Sie die Last dem auslösenden Projekt zu. Bei den recherchierten Managed-Tarifen nennt die Anbieterkarte NVMe; einzelne Produktkonfiguratoren verwenden teilweise die allgemeinere Bezeichnung SSD. Diese Abweichung wird auf den Tarifseiten sichtbar gemacht. Für eine verbindliche Auswahl fragen Sie nach der tatsächlichen bereitgestellten Speicherkonfiguration. Eine Marketingbezeichnung sollte nicht als garantierter Messwert für jede beliebige Anwendung behandelt werden.
Hintergrundjobs in die Planung aufnehmen
WordPress und Erweiterungen können regelmäßige Aufgaben starten: Daten abgleichen, Berichte erstellen, Nachrichten vorbereiten oder temporäre Dateien bereinigen. Hinzu kommen Sicherungen und Cachevorwärmung. Diese Arbeit fällt auch dann an, wenn kaum normale Besucher auf der Website sind. Bei mehreren Projekten können gleichzeitig beginnende Jobs eine vermeidbare Lastspitze bilden.
Erstellen Sie eine Übersicht mit Aufgabe, Projekt, Zeitplan, erwarteter Dauer und Verantwortlichem. Entzerren Sie Termine nach Prüfung der fachlichen Anforderungen. Ein täglich benötigter Warenabgleich darf nicht beliebig verschoben werden, ein unkritischer Bericht möglicherweise schon. Kontrollieren Sie außerdem, ob ein Job erneut beginnt, während die vorherige Ausführung noch läuft. Solche Überlappungen können Ressourcen aufstauen. Änderungen am Zeitplan werden dokumentiert und anschließend beobachtet. So gewinnt der vorhandene Server oft Spielraum, ohne sofort eine größere Tarifstufe zu benötigen. Bei der WordPress-Verwaltung in Plesk bleiben Zweck, Zuständigkeit und Ergebnis jedes geplanten Jobs nachvollziehbar.
Staging und Updates als echte Last berücksichtigen
Testumgebungen werden bei der Kapazitätsplanung häufig vergessen. Eine Kopie benötigt Dateien und Datenbank; während Tests kann sie außerdem dynamische Last erzeugen. Updates, Pluginwechsel und Bildverarbeitung beanspruchen zeitweise zusätzliche Ressourcen. Wenn mehrere Mitarbeiter gleichzeitig an unterschiedlichen Kundenprojekten arbeiten, ist das kein seltenes Ausnahmeereignis, sondern ein normaler Teil des Agenturbetriebs.
Legen Sie fest, welche Teststände dauerhaft bestehen bleiben und welche nach einer Freigabe entfernt werden können. Schützen Sie sie vor öffentlicher Indexierung und unerwünschten produktiven Aktionen. Nutzen Sie passende Daten und verhindern Sie versehentliche Benachrichtigungen oder Bestellungen aus der Kopie. Diese organisatorischen Regeln beeinflussen den Ressourcenbedarf: Eine vollständige Kopie ist nicht immer für jede kleine Änderung nötig, für riskantere Anpassungen jedoch oft hilfreich. Planen Sie einen überschaubaren Standard, statt Teststände ungeordnet anzuhäufen. Für Staging und die Updatefreigabe werden die benötigten Teststände mit ihrem Zweck und Rückweg festgelegt.
Backups benötigen Kapazität und ein Zeitfenster
Sicherungen beanspruchen je nach Verfahren Speicher, Rechenzeit und Ein- sowie Ausgabe. Wenn sie in einer ohnehin stark genutzten Phase laufen, können sie andere Aufgaben beeinflussen. Eine Backupplanung gehört deshalb zur Dimensionierung. Erfassen Sie Umfang, Häufigkeit und Dauer. Prüfen Sie, ob temporäre Dateien auf dem Produktivdatenträger entstehen und ob genügend Platz für einen vollständigen Sicherungslauf vorhanden ist.
Backupspeicher wird nach dem gewünschten Aufbewahrungsplan kalkuliert, nicht allein als Vielfaches einer Tarifzahl. Eine vollständige Sicherung und mehrere inkrementelle Stände können unterschiedlichen Platz brauchen. Wie viel tatsächlich belegt wird, hängt von Änderungsrate und Verfahren ab. Messen Sie eine repräsentative Reihe und dokumentieren Sie deren Entwicklung. Die zusätzliche Backupkapazität der Managed-Tarife ist auf den Produktseiten getrennt vom Serverdatenträger ausgewiesen. Details zu Aufbewahrung und Wiederherstellung müssen dennoch bestätigt werden. Die Backupplanung mit Restore-Prüfung macht den tatsächlichen Platzbedarf und die notwendigen Arbeitsschritte sichtbar.
Mehrere Kunden mit passenden Grenzen organisieren
Auf einer gemeinsamen Umgebung teilen Kundenprojekte die Gesamtressourcen. Ein einzelner Import oder ein fehlerhaft laufender Prozess kann andere Websites beeinträchtigen. Geeignete Kontentrennung und nachvollziehbare Grenzen helfen, solche Folgen zu begrenzen. Bei CloudLinux können beispielsweise verschiedene Ressourcen je Konto beobachtet und begrenzt werden. Welche Funktionen auf dem gebuchten System verfügbar sind, muss konkret geprüft werden.
Beginnen Sie mit einer Projektklassifizierung nach tatsächlicher Last. Kleine Informationsseiten benötigen andere Grenzen als ein dynamischer Shop. Prüfen Sie anschließend, ob Fehlereignisse oder wiederholte Grenzverletzungen auftreten. Eine Grenze wird nicht allein deshalb aufgehoben, weil sie erreicht wurde; zuerst wird die Ursache betrachtet. Ebenso wenig sollte eine zu enge Vorgabe unverändert bleiben, wenn sie normale benötigte Arbeit blockiert. Die Gesamtplanung und die Kontogrenzen müssen zusammenpassen. Halten Sie die Werte und Gründe schriftlich fest, damit spätere Mitarbeiter die Aufteilung verstehen und Änderungen gezielt vornehmen können.
Netzwerk und Traffic ohne falsche Gleichsetzung vergleichen
Ein beworbener Netzwerkanschluss beschreibt nicht automatisch eine dauerhaft exklusive Übertragungsrate bis zu jedem Besucher. Die Auslieferung hängt auch vom Weg durch das Internet, vom Browser und von den übertragenen Dateien ab. Trafficangaben brauchen zudem einen Zeitraum und eine Regel für Überschreitungen. Ohne diese Informationen lässt sich eine Monatsplanung nicht vollständig aus der einzelnen Gigabytezahl ableiten.
Schätzen Sie für typische Seiten zunächst die übertragene Datenmenge und beobachten Sie vorhandene Messwerte. Große Medien können den Traffic stärker beeinflussen als zusätzliche Textseiten. Downloads verdienen eine separate Betrachtung. Fragen Sie nach Abrechnungszeitraum, Limits und möglicher Drosselung. Bei den hier recherchierten Managed-Produkten sind Trafficwerte im Shop sichtbar, aber Zeitraum und Überschreitungsregeln nicht vollständig bestätigt. Die Tarifseiten behandeln das ausdrücklich als offenen Punkt. Eine Dimensionierung sollte solche Angaben nicht stillschweigend in unbegrenzten Traffic umdeuten, sondern die notwendige Klärung vor der Bestellung benennen.
Mit repräsentativen Tests arbeiten
Ein Lasttest soll eine konkrete Frage beantworten, beispielsweise ob eine Kampagnenseite bei erwarteten gleichzeitigen Zugriffen ausreichend schnell antwortet. Dafür werden typische Seitentypen und realistische Abläufe ausgewählt. Eine ausschließlich statische Startseite misst nicht die Kapazität eines personalisierten Bereichs. Ebenso kann ein Test ohne aktive Hintergrundjobs eine zu günstige Situation zeigen.
Führen Sie Tests in einer dafür vorgesehenen Umgebung und nach Abstimmung durch. Steigern Sie die Last kontrolliert und beobachten Sie Antwortzeiten, Fehler und Ressourcen. Notieren Sie die genauen Testbedingungen. Nutzen Sie keine unkoordinierten Belastungsversuche gegen produktive Kundensysteme. Nach dem Test wird ausgewertet, welcher Engpass zuerst auftrat und ob die Anwendung korrekt blieb. Das Ergebnis beschreibt genau dieses Szenario, keine universelle Maximalzahl für alle Websites. Wiederholen Sie nur, wenn eine relevante Änderung oder eine offene Frage es begründet. So bleiben Messung und Interpretation nachvollziehbar.
Was sagen die Messwerte gemeinsam aus?
Ein hoher CPU-Wert kann bei einem geplanten Import kurzzeitig erwartbar sein. Ein dauerhaft hoher Speicherverbrauch kann teilweise aus nützlichem Cache bestehen. Einzelne Zahlen müssen deshalb mit den tatsächlichen Symptomen und dem Zeitraum verbunden werden. Prüfen Sie, ob Nutzer Verzögerungen oder Fehler erleben und welche Aufgabe gleichzeitig läuft. Eine ruhige Momentaufnahme schließt vorherige Spitzen nicht aus.
Erstellen Sie bei Problemen eine kleine Zeitleiste mit Anfrageverhalten, Ressourcendaten und Änderungen. Markieren Sie, welche Beobachtung gesichert ist und welche Ursache noch vermutet wird. Falls die Startseite schnell lädt, der Verwaltungsbereich aber langsam bleibt, kann die nicht zwischengespeicherte Arbeit entscheidend sein. Wenn CPU frei ist, aber viele Prozesse warten, wird die Warteursache untersucht. Dieses Vorgehen verhindert voreilige Tarifwechsel. Mehr Leistung ist eine mögliche Maßnahme, aber sie sollte den belegten Engpass treffen. Die gemeinsame Analyse mit Anbieter und Agentur wird dadurch wesentlich konkreter.
Die drei Managed-Stufen als Ausgangsdaten verwenden
Die aktuell recherchierten Angebote der webhoster.de AG nennen für Startup 4 vCPU, 16 Gigabyte RAM und 200 Gigabyte Serverdatenträger, für Business 8 vCPU, 32 Gigabyte RAM und 500 Gigabyte sowie für Agency 16 vCPU, 64 Gigabyte RAM und 1.000 Gigabyte. Diese Größen geben einen Rahmen für den Vergleich. Sie sind keine zugesagten Besucher- oder Shopkapazitäten und ersetzen keine Prüfung des konkreten Projekts.
Beachten Sie dazu Verwaltungseditionen, Backupspeicher und die auf den Detailseiten benannten offenen Punkte. Wenn mehrere Ressourcen gleichzeitig wachsen, kann eine andere Stufe sinnvoll sein. Wenn nur eine schlecht arbeitende Funktion Last erzeugt, beginnt die Maßnahme dagegen bei der Anwendung. Die Seiten Startup, Business und Agency führen zu den Originalprodukten. Betreiber dieses werblich gekennzeichneten Portals ist die iSearch GmbH; Anbieter und Vertragspartner des jeweiligen Produkts ist die webhoster.de AG.
Die Tabelle lässt sich seitlich verschieben.
| Tarif | vCPU / RAM | Serverdatenträger | Zusätzlicher Plesk-Backupplatz |
|---|---|---|---|
| Startup | 4 / 16 GB | 200 GB | 600 GB |
| Business | 8 / 32 GB | 500 GB | 1500 GB |
| Agency | 16 / 64 GB | 1000 GB | 3000 GB |
Reserve für konkrete Vorhaben festlegen
Reserven sollten aus bekannten Aufgaben abgeleitet werden. Dazu gehören Spitzen, Updates, Testkopien und erwartetes Wachstum. Legen Sie für jede wichtige Ressource fest, weshalb zusätzlicher Spielraum nötig ist. Eine einzige pauschale Prozentzahl kann als interne Orientierung dienen, sollte aber nicht als technisch allgemeingültige Regel ausgegeben werden. Der sinnvoll freie Speicher hängt beispielsweise von Sicherungsverfahren und temporären Dateien ab.
Planen Sie außerdem den Zeitpunkt einer erneuten Prüfung. Wenn ein weiterer Shop startet oder eine umfangreiche Mediensammlung wächst, wird der Ressourcenplan aktualisiert. Klären Sie mit dem Anbieter, wie Erweiterungen durchgeführt werden und welche Unterbrechung dafür nötig sein kann. Ohne bestätigten Ablauf darf ein Upgrade nicht als jederzeit folgenlos angenommen werden. Eine dokumentierte Reserve hilft dem Team, rechtzeitig zu handeln. Sie erleichtert auch die Begründung eines Tarifwechsels, weil sichtbar ist, welche neue Aufgabe die bisherige Planung verändert hat.
Die Dimensionierung als Betriebsdokument fortführen
Fassen Sie die Auswahl in einem kurzen Dokument zusammen: aktive Projekte, wichtigste Lastarten, gemessene Spitzen, benötigte Ressourcen, Reserven und offene Angaben. Ergänzen Sie Zuständigkeiten für Messung und Änderungen. Das Dokument muss kein kompliziertes Rechenmodell sein. Es soll erklären, warum die gewählte Umgebung heute passt und wann sie erneut geprüft werden muss.
Nach dem Start werden tatsächliche Werte mit den Annahmen verglichen. Größere Abweichungen werden untersucht, statt einfach immer höhere Grenzen einzustellen. Bei einer neuen Erweiterung oder einem größeren Import wird die Planung gezielt aktualisiert. Halten Sie zudem die Ergebnisse von Backup- und Wiederherstellungstests fest, weil sie Zeitfenster und Ressourcen beeinflussen. So bleibt die Dimensionierung ein praktisches Arbeitsmittel. Der Server wird anhand seiner Aufgabe beurteilt, und Entscheidungen über Optimierung, getrennte Projekte oder einen größeren Tarif lassen sich mit verständlichen Belegen treffen.