Ein Shop läuft im Tagesgeschäft unauffällig - bis eine Kampagne startet, ein Newsletter versendet wird oder das Weihnachtsgeschäft anzieht. Dann entscheidet nicht der gebuchte Tarif über den Erfolg, sondern die tatsächlich verfügbare Leistung. Webhosting-Kapazität richtig planen heißt deshalb, Last, Wachstum und Ausfallrisiken vor dem Engpass einzuordnen. Wer nur Speicherplatz und monatlichen Traffic betrachtet, übersieht die Komponenten, die Ladezeit, Conversion und Verfügbarkeit bestimmen.
Für geschäftskritische Websites ist Kapazitätsplanung keine einmalige Bestellung. Sie ist ein Betriebsprozess: Welche Last entsteht heute? Wo liegen die Spitzen? Welche Reserven braucht das Projekt? Und wie lässt sich zusätzliche Leistung bereitstellen, ohne den Betrieb zu unterbrechen?
Kapazität ist mehr als Speicherplatz
Viele Hosting-Angebote reduzieren Kapazität auf Gigabyte für Dateien, Datenbanken und E-Mails. Das ist für kleine, statische Websites ein brauchbarer erster Wert. Für Onlineshops, Portale, Odoo-Installationen oder Lernplattformen reicht er nicht aus.
Entscheidend ist das Zusammenspiel mehrerer Ressourcen. CPU-Leistung verarbeitet PHP-Anfragen, Hintergrundjobs und Suchindizierungen. Arbeitsspeicher hält Prozesse, Datenbank-Caches und Redis-Inhalte verfügbar. NVMe-Speicher beeinflusst die Geschwindigkeit von Datenbankzugriffen und Dateisystemoperationen. Netzwerkbandbreite und die Zahl gleichzeitig möglicher Verbindungen bestimmen, ob viele Besucher parallel zuverlässig bedient werden. Dazu kommen Datenbankleistung, Cache-Strategie und die Architektur der Anwendung selbst.
Ein Shop mit 20.000 Artikeln kann bei wenig Traffic weniger Ressourcen benötigen als ein kleinerer Shop mit komplexen Varianten, vielen API-Anbindungen und personalisierten Preisen. Auch Plugins, schlecht optimierte Datenbankabfragen oder umfangreiche Importprozesse verändern das Lastprofil erheblich. Eine Kapazitätsplanung muss daher das konkrete Projekt bewerten - nicht nur die Größe des Produktkatalogs oder eine pauschale Besucherzahl.
Erst das Lastprofil verstehen, dann Infrastruktur festlegen
Die wichtigste Frage lautet nicht: „Wie viel Webspace brauchen wir?“ Sondern: „Wann und wodurch entsteht Last?“ Dafür sollten technische Kennzahlen mit den Geschäftsprozessen zusammengeführt werden.
Relevant sind durchschnittliche und maximale gleichzeitige Besucher, Seitenaufrufe, Bestellvorgänge, API-Requests sowie die Verteilung über den Tag. Bei E-Commerce-Projekten kommen Warenkorb- und Checkout-Last, Suchanfragen, Zahlungsanbieter, ERP- oder PIM-Schnittstellen und Cronjobs hinzu. Eine nächtliche Preisaktualisierung kann beispielsweise dieselbe Datenbank belasten, die am Morgen wieder schnelle Shop-Anfragen beantworten soll.
Besonders aussagekräftig sind historische Daten. Webanalyse, Server-Monitoring, Datenbankmetriken und Application-Performance-Daten zeigen, ob Engpässe bei CPU, RAM, I/O oder externen Diensten auftreten. Fehlen diese Werte, helfen belastbare Annahmen: geplante Marketingaktionen, Saisonspitzen, neue Länder-Shops, B2B-Kundenportale oder erwartete Sortimentsausweitungen.
Dabei gilt: Durchschnittswerte beruhigen oft zu Unrecht. Wenn ein Shop im Mittel zehn Anfragen pro Sekunde verarbeitet, kann eine Kampagne kurzfristig ein Vielfaches auslösen. Die Infrastruktur muss nicht dauerhaft für die seltenste Extremsituation überdimensioniert sein. Sie braucht aber klar definierte Reserven und einen getesteten Weg zur Skalierung.
Lastspitzen gehören zum Normalbetrieb
Black Friday, TV-Erwähnungen, Ticketverkäufe oder ein erfolgreicher Social-Media-Post sind keine technischen Ausnahmen. Für das Geschäft sind sie häufig die wertvollsten Zeitfenster. Wer Kapazität allein nach dem Normalbetrieb bestellt, riskiert genau dann langsame Seiten oder nicht erreichbare Checkouts, wenn Nachfrage vorhanden ist.
Sinnvoll ist eine Planung mit ausreichend Leistungsreserve für erwartbare Spitzen. Wie groß diese Reserve sein muss, hängt von Reaktionszeit und Skalierungsmodell ab. Kann zusätzliche Serverleistung kurzfristig und ohne Downtime bereitgestellt werden, darf die Grunddimensionierung schlanker ausfallen. Ist ein System nur mit Wartungsfenster erweiterbar, müssen die Reserven größer sein.
Webhosting-Kapazität richtig planen: Die kritischen Bausteine
Bei professionellen Webprojekten sollte die Infrastruktur entlang der tatsächlichen Verarbeitungskette geplant werden. Ein schneller Webserver allein löst kein Problem, wenn die Datenbank wartet oder ein externer Dienst blockiert.
Für dynamische Anwendungen ist die Zahl parallel arbeitender PHP-Prozesse ein zentraler Faktor. Zu wenige Worker erzeugen Warteschlangen, obwohl CPU und RAM scheinbar noch frei sind. Zu viele Prozesse können dagegen den Arbeitsspeicher erschöpfen und die Datenbank zusätzlich unter Druck setzen. Die passende Einstellung hängt unter anderem von der durchschnittlichen Ausführungszeit, dem Speicherbedarf pro Prozess und der erwarteten Parallelität ab.
Bei Shopware und vergleichbaren Plattformen verdienen Redis, Elasticsearch oder OpenSearch sowie MariaDB besondere Aufmerksamkeit. Redis reduziert wiederkehrende Zugriffe durch Caching und Session-Verwaltung. Die Suchplattform verarbeitet Produkt- und Filteranfragen. MariaDB trägt Transaktionen, Warenkörbe und Bestellungen. Werden diese Komponenten auf einer gemeinsamen, zu knapp bemessenen Instanz betrieben, konkurrieren sie um RAM und I/O. Bei wachsender Last ist die Trennung einzelner Rollen oft sinnvoller als ein immer größerer Einzelserver.
Auch der Content Delivery Network- und Sicherheitslayer gehört zur Kapazitätsplanung. Ein CDN entlastet den Ursprungsserver bei Bildern, Skripten und anderen statischen Dateien. Eine Web Application Firewall filtert unerwünschte Anfragen, bevor sie die Anwendung erreichen. Beides ersetzt keine leistungsfähige Kerninfrastruktur, kann aber planbare Last vom System fernhalten und die verfügbare Kapazität für echte Nutzer reservieren.
Skalierung: vertikal, horizontal oder hochverfügbar?
Vertikale Skalierung bedeutet: Ein Server erhält mehr CPU-Kerne, Arbeitsspeicher oder schnelleren Speicher. Das ist einfach zu administrieren und für viele Projekte der richtige erste Schritt. Die Grenze liegt in der maximal verfügbaren Hardware - und darin, dass ein einzelnes System weiterhin ein möglicher Ausfallpunkt bleibt.
Horizontale Skalierung verteilt Webanfragen auf mehrere Instanzen hinter einem Load Balancer. Sie eignet sich besonders für Anwendungen, deren Web- und PHP-Schicht weitgehend zustandslos betrieben werden kann. Sessions, Caches, Uploads und Hintergrundjobs müssen dafür sauber ausgelagert oder synchronisiert sein. Das erhöht die Komplexität, schafft aber Kapazität und Redundanz.
Hochverfügbarkeit geht einen Schritt weiter. Redundante Komponenten, replizierte Datenbanken, Failover-Mechanismen und kontinuierliches Monitoring sollen verhindern, dass der Ausfall eines einzelnen Systems direkt zum Ausfall des Dienstes führt. Das ist nicht für jede Unternehmenswebsite wirtschaftlich erforderlich. Für umsatzkritische Shops, Kundenportale oder Plattformen mit verbindlichen Verfügbarkeitsanforderungen ist „Hochverfügbarkeit statt Hoffnung“ jedoch eine betriebliche Entscheidung, keine Komfortfunktion.
Kapazität ohne Monitoring ist nur eine Vermutung
Eine Infrastruktur kann nur verlässlich wachsen, wenn ihre Auslastung sichtbar ist. Monitoring sollte nicht erst bei einer Störung beginnen. CPU-Auslastung, RAM-Verbrauch, I/O-Wait, Datenbankverbindungen, Antwortzeiten, Fehlerquoten, Queue-Längen und Speicherwachstum zeigen frühzeitig, wo Handlungsbedarf entsteht.
Für die Nutzererfahrung sind technische Systemwerte allein nicht genug. Relevant sind auch Time to First Byte, Ladezeiten wichtiger Seiten, Erfolgsquoten im Checkout und die Antwortzeit von Schnittstellen. Eine Ziel-TTFB von unter 200 Millisekunden kann ein sinnvoller Orientierungswert sein, muss aber im Kontext der Anwendung und der Messmethode bewertet werden. Eine dynamische, personalisierte Seite stellt andere Anforderungen als eine gecachte Kategorieseite.
Schwellwerte und Alarmierungen sollten so gesetzt sein, dass Teams vor dem Ausfall reagieren können. Gleichzeitig darf nicht jede kurzfristige Lastspitze einen Alarm auslösen. Entscheidend sind Dauer, Entwicklung und geschäftliche Relevanz eines Ereignisses. Wiederkehrende Warnungen bei Datenbanklast oder knappem Speicher sind kein Rauschen, sondern Hinweise für die nächste Kapazitätsentscheidung.
Kosten planbar halten, ohne an der falschen Stelle zu sparen
Überdimensionierung bindet Budget. Unterdimensionierung kostet Umsatz, Vertrauen und im Ernstfall viel Zeit für Notmaßnahmen. Die wirtschaftlich beste Lösung ist deshalb selten der kleinste Server und ebenso selten die größte verfügbare Konfiguration.
Planbar wird der Betrieb durch eine nachvollziehbare Grundlast, definierte Reserven und einen vereinbarten Skalierungsprozess. Dazu gehören klare Zuständigkeiten, realistische Reaktionszeiten und regelmäßige Reviews nach Releases, Kampagnen oder Wachstumsschritten. Backups müssen dabei getrennt von der Produktionskapazität gedacht werden. Sie schützen Daten, ersetzen aber weder Redundanz noch eine getestete Wiederherstellung.
Hostingwerft plant solche Umgebungen projektbezogen - vom optimierten Einzelserver bis zur skalierbaren Cluster-Architektur mit Managed Betrieb, Monitoring und deutschem Datenstandort. Entscheidend bleibt dabei nicht das Paket, sondern die Frage, welche Infrastruktur Ihr Projekt im Alltag und unter Last tatsächlich benötigt.
Die beste Zeit für eine Kapazitätsprüfung ist nicht nach dem ersten Timeout im Checkout. Prüfen Sie Lastprofile, Reserven und Skalierungswege, solange Ihr System noch ruhig läuft. Dann wird Wachstum zur planbaren Betriebsaufgabe statt zum Risiko im entscheidenden Moment.