Wie viele Besucher verträgt mein Hosting? Kapazität berechnen

Wie viele Besucher verträgt mein Hosting?

Wie viele Besucher verträgt mein Hosting, hängt nicht von der monatlichen Besucherzahl ab, sondern von den Anfragen pro Sekunde in der Spitze, multipliziert mit der Bearbeitungszeit jeder Anfrage. Eine gecachte Seite trägt auf demselben Server weit mehr Besucher als eine ungecachte. Deshalb gibt es keine feste Zahl, sondern eine Rechnung.

In diesem Ratgeber bauen wir diese Rechnung Schritt für Schritt auf. Unser Ziel ist also keine magische Zahl. Stattdessen sollen Sie die Kapazität mit den Daten Ihrer eigenen Website grob, aber ehrlich abschätzen. Alle Zahlen unten tragen das Etikett „Rechenbeispiel“. Ersetzen Sie sie deshalb durch Werte aus Ihrem Hostingpanel, Ihrer Webanalyse und Ihren Serverlogs.

Wir sind Talha Aslan und Team, ein Team für digitales Marketing und Webentwicklung, kein Hostinganbieter. Diese Frage begegnet uns in Website und E-Commerce Projekten häufig. Daher stützen wir technische Details auf offizielle Dokumentation und nennen die Quellen direkt im Text.

Warum führt die monatliche Besucherzahl in die Irre?

Die monatliche Besucherzahl ist die Summe aller Menschen, die Ihre Website in einem Monat erreichen. Ein Server bearbeitet allerdings keinen Monat. Er bearbeitet vielmehr die Anfragen, die in derselben Sekunde ankommen, denn nur diese konkurrieren um Ressourcen.

Stellen Sie sich zwei Websites mit jeweils 100.000 Besuchern im Monat vor. Die erste bekommt den ganzen Monat über gleichmäßigen Traffic. Die zweite drängt einen großen Teil ihres Traffics nach einer einzigen Werbemail in wenige Stunden. Folglich braucht die zweite Website bei gleicher Monatszahl eine deutlich stärkere Infrastruktur.

Zudem sagt das Wort „Besucher“ nichts über die Arbeitslast. Ein Besucher liest eine Seite und geht. Ein anderer filtert Produkte, legt Artikel in den Warenkorb und geht zur Kasse. Dieser zweite Besucher belastet den Server daher viel stärker.

Kurz gesagt: Die Monatszahl ist eine Kennzahl für Traffic und Budget, nicht für Kapazität. Für die Kapazität brauchen Sie Antworten auf drei Fragen:

• Wie viele Seitenaufrufe pro Sekunde entstehen in der stärksten Minute?
• Wie viele dynamische Anfragen erzeugt jeder Seitenaufruf auf dem Server?
• Wie lange dauert jede dieser Anfragen im Durchschnitt?

Sobald Sie diese drei Werte kennen, sehen Sie genau, wo Ihr Hostingtarif an seine Grenzen stößt.

Was unterscheidet gleichzeitige Nutzer von gleichzeitigen Anfragen?

Gleichzeitige Nutzer sind die Personen, die im selben Zeitfenster auf Ihrer Website aktiv sind. Gleichzeitige Anfragen sind dagegen die Anfragen, die Ihr Server genau in diesem Moment bearbeitet. Konkret liegen beide Zahlen meist weit auseinander.

Zum Beispiel zeigt der Echtzeitbericht von Google Analytics 4 laut der Google Analytics Hilfe die Nutzeraktivität der letzten 30 Minuten. Sehen Sie dort 300 aktive Nutzer, bearbeitet Ihr Server also keineswegs 300 Anfragen auf einmal. Die meisten Nutzer lesen, scrollen oder betrachten in einer bestimmten Sekunde ein Bild. Ihr Browser fordert vom Server also nichts Neues an.

Rechenbeispiel: Öffnet jeder der 300 aktiven Nutzer im Schnitt alle 60 Sekunden eine neue Seite, entstehen rund 5 Seitenaufrufe pro Sekunde. Dauert die serverseitige Arbeit je Seite 0,5 Sekunden, laufen im Schnitt etwa 2,5 Anfragen gleichzeitig. Anders gesagt: Aus einer Menge von 300 Menschen werden für den Server eine Handvoll paralleler Aufgaben.

Diese Unterscheidung bildet somit den Kern der Kapazitätsrechnung. Übersetzen Sie daher die Frage „Wie viele Menschen passen gleichzeitig drauf?“ in die Frage „Wie viele Anfragen pro Sekunde, und wie viele Sekunden dauert jede?“.

Wie berechnen Sie Anfragen pro Sekunde (RPS)?

Anfragen pro Sekunde (RPS, requests per second) sind die Anfragen, die Ihren Server innerhalb einer Sekunde erreichen. Für die Kapazität zählen vor allem dynamische Anfragen, denn nur sie führen auf dem Server Code aus.

Die Grundformel lautet:

dynamische RPS = Seitenaufrufe pro Sekunde x dynamische Anfragen pro Seite

Für die Seitenaufrufe pro Sekunde teilen Sie die Seitenaufrufe der Spitzenstunde durch 3.600. Dann multiplizieren Sie das Ergebnis mit der Zahl der dynamischen Anfragen pro Seite. Bei WordPress ist das HTML der Seite selbst eine dynamische Anfrage. Außerdem lösen manche Themes und Plugins im Hintergrund Aufrufe an admin ajax oder die REST API aus.

Statische Dateien, also CSS, JavaScript, Bilder und Schriften, sind ebenfalls Anfragen. Allerdings liefert der Webserver sie direkt von der Festplatte oder aus dem Cache aus; PHP und Datenbank bleiben außen vor. Zählen Sie statische Anfragen deshalb getrennt. Sie beeinflussen vor allem Bandbreite und Verbindungszahl, kaum aber die Prozessorlast.

Ohne diese Trennung unterschätzen Sie entweder Ihre Kapazität, oder Sie übersehen den eigentlichen Engpass: die PHP Ebene.

Wie finden Sie die Last in der Spitzenstunde?

Die Spitzenlast ist der Traffic im stärksten Zeitfenster Ihrer Website. Sie planen die Kapazität deshalb für diese Spitze, nicht für den Durchschnitt. Schließlich wird eine Website im stärksten Moment langsam, nicht in einem durchschnittlichen.

Am einfachsten finden Sie die Spitzenstunde über die stündliche Verteilung in Ihrem Analysetool. In GA4 können Sie Berichte nach Stunde aufschlüsseln und sehen, welche Stunden herausragen. Danach notieren Sie die Seitenaufrufe dieser Stunde.

Rechenbeispiel: Eine Website mit 10.000 Seitenaufrufen am Tag erhält in der stärksten Stunde 12 Prozent ihres Tagestraffics. Diese Stunde hat dann 1.200 Seitenaufrufe, also rund 0,33 Seitenaufrufe pro Sekunde. Die 12 Prozent sind eine reine Annahme; setzen Sie Ihre eigenen Daten ein.

Trotzdem verdeckt selbst ein Stundenmittel kurze Spitzen. Verschicken Sie einen Newsletter oder starten Sie eine Kampagne, drängt sich der Traffic in wenige Minuten. Deshalb empfehlen wir einen zusätzlichen Spitzenfaktor:

• Bei gleichmäßigem, überwiegend organischem Traffic reicht oft ein niedriger Faktor.
• Bei Websites mit Aktionen per E-Mail, SMS oder Social Media halten Sie den Faktor hoch.
• Für Fernsehwerbung oder große Rabatttage erstellen Sie einen eigenen Plan.

Wie Sie Ausfälle in Kampagnenphasen vermeiden, behandeln wir in einem eigenen Artikel. Hier konzentrieren wir uns dagegen nur auf die Logik der Rechnung, denn sie gilt für jeden Anlass.

Wie viele Anfragen sendet ein Seitenaufruf an den Server?

Ein Seitenaufruf endet selten mit einer einzigen Anfrage. Zunächst fordert der Browser das HTML an. Danach lädt er Stylesheets, Skripte, Bilder und Schriften, auf die das Dokument verweist. Bei einer modernen Seite kommen daher schnell Dutzende Anfragen zusammen.

Ihre eigene Zahl sehen Sie in den Entwicklertools Ihres Browsers. Öffnen Sie zunächst den Tab Netzwerk und laden Sie dann die Seite neu. Unten stehen die Gesamtzahl der Anfragen und die übertragene Datenmenge. Zudem können Sie nach Typ filtern und so das Dokument von Aufrufen per XHR oder fetch trennen.

Für die Kapazität hilft eine Einteilung in drei Gruppen:

1. Die dynamische Dokumentanfrage: das HTML der Seite. Ohne Cache laufen dafür PHP und Datenbank.
2. Dynamische Hintergrundaufrufe: Warenkorb aktualisieren, Livesuche, Formulare absenden.
3. Statische Dateien: CSS, JS, Bilder und Schriften. Diese liefert der Webserver oder ein CDN aus.

In der Rechnung zählen die ersten beiden Gruppen als „dynamische Anfragen pro Seite“. Die dritte Gruppe gehört dagegen in die Rechnung für Bandbreite und Datentransfer. So trennen Sie die Arbeit, die den Prozessor belastet, von der Arbeit, die das Netzwerk belastet.

Wie hilft Littles Gesetz bei der Kapazitätsrechnung?

Littles Gesetz besagt: Die durchschnittliche Zahl der Aufgaben in einem System entspricht der Ankunftsrate multipliziert mit der durchschnittlichen Verweildauer jeder Aufgabe. Kurz geschrieben lautet es L = λW. John D. C. Little bewies das Ergebnis 1961 und blickte später in einem Fachartikel in Operations Research auf die ersten fünfzig Jahre zurück.

Auf einen Webserver übertragen, sieht die Formel so aus:

gleichzeitige Anfragen = Anfragen pro Sekunde x mittlere Antwortzeit (Sekunden)

Rechenbeispiel: Kommen pro Sekunde 4 dynamische Anfragen an und dauert jede im Schnitt 0,5 Sekunden, bearbeitet der Server im Mittel 2 Anfragen gleichzeitig. Steigt die Antwortzeit auf 2 Sekunden, hält derselbe Traffic plötzlich 8 Anfragen parallel im System.

Vor allem dieser letzte Punkt ist entscheidend. Auch bei gleichem Traffic füllt eine längere Antwortzeit den Server. Eine langsame Datenbankabfrage oder ein Plugin, das auf eine externe API wartet, frisst die Kapazität direkt auf. Somit haben Sie zwei Hebel: mehr Ressourcen oder schnellere Anfragen.

Sie können die Formel auch umdrehen. Teilen Sie die Zahl Ihrer Worker durch die mittlere Antwortzeit, dann erhalten Sie die höchste dynamische Anfragerate, die Sie pro Sekunde tragen können.

Warum bestimmen PHP Worker Ihre echte Kapazität?

Die Zahl der PHP Worker ist die Obergrenze an PHP Prozessen, die Ihr Server gleichzeitig ausführen kann. Bei PHP FPM legt die Direktive pm.max_children diese Grenze fest. Die offizielle PHP Dokumentation schreibt ausdrücklich, dass diese Option die Zahl gleichzeitig bedienter Anfragen begrenzt.

Mit 8 Workern bearbeitet der Server also höchstens 8 dynamische Anfragen auf einmal. Die neunte Anfrage wartet also, bis ein Worker frei ist. Eine kurze Wartezeit spürt der Nutzer nur als Langsamkeit. Eine lange Warteschlange führt dagegen zu Zeitüberschreitungen und Fehlern wie 502 oder 503. Wie Sie diesen Fehler eingrenzen, zeigt unser Ratgeber zu 503 Service Unavailable.

Erreicht FPM die Grenze, schreibt es eine Warnung in sein Fehlerprotokoll. Finden Sie dort Zeilen, nach denen der Pool die Einstellung max_children erreicht hat, dann wissen Sie: Sie haben die Kapazitätsgrenze berührt.

Allerdings löst eine unbegrenzte Erhöhung der Worker nichts. Jeder Worker braucht Arbeitsspeicher und teilt sich die Prozessorkerne mit den anderen. Setzen Sie die Zahl weit über das, was der Prozessor schafft, warten Anfragen nicht mehr in der Schlange, sondern alle laufen gemeinsam langsamer. Daher stimmen Sie die Worker immer auf Prozessor und Arbeitsspeicher zugleich ab.

Wie groß ist der Unterschied zwischen gecachten und ungecachten Seiten?

Bei einer ungecachten Seite führt jeder Besuch PHP Code aus, fragt die Datenbank ab und baut das HTML neu. Mit einem Seitencache schickt der Server fertiges HTML direkt von der Festplatte oder aus dem Arbeitsspeicher. In den meisten Fällen springt dabei gar kein PHP Worker an.

Das verändert die Kapazitätsrechnung folglich grundlegend. Die „mittlere Antwortzeit“ in Littles Gesetz sinkt durch den Cache deutlich, und damit sinkt auch der Bedarf an gleichzeitigen Workern. Das genaue Verhältnis ermitteln Sie mit eigenen Messungen, denn Theme, Plugins und Serversoftware prägen das Ergebnis.

Caching hat mehrere Ebenen:

• Seitencache: speichert fertiges HTML und bringt den größten Kapazitätsgewinn.
• Opcode Cache: hält kompilierten PHP Code im Speicher. Details finden Sie in unserem Ratgeber zu OPcache.
• Objektcache: hält häufige Datenbankergebnisse im Speicher. Unser Artikel zu Redis und Memcached erklärt diese Ebene.

Andererseits sind Warenkorb, Kundenkonto und Kasse personalisiert und bleiben daher meist außerhalb des Caches. Bei einem Onlineshop schätzen Sie also cachebaren und nicht cachebaren Traffic getrennt.

Wie schätzen Sie die Kapazität aus Prozessor und Arbeitsspeicher?

Die Zahl der Worker hat zwei natürliche Obergrenzen: Arbeitsspeicher und Prozessor. Berechnen Sie beide und nehmen Sie die niedrigere als echte Grenze.

Für die Speichergrenze nutzen Sie diese Formel:

max. Worker (RAM) = (RAM gesamt - Anteil anderer Dienste) / mittlerer Speicher je Worker

Zum Anteil anderer Dienste zählen Betriebssystem, Datenbank, Webserver und ein eventueller Cachedienst. Der Speicher je Worker hängt von Ihrer Anwendung ab; eine Website mit vielen Plugins braucht mehr. Konkret messen Sie ihn, indem Sie den Speicherverbrauch der laufenden PHP Prozesse auf dem Server prüfen.

Für die Prozessorgrenze gehen Sie ähnlich vor:

max. dynamische RPS (CPU) = Prozessorkerne / mittlere Rechenzeit je Anfrage

Rechenbeispiel: Auf einem Server mit zwei Kernen verbraucht jede dynamische Anfrage im Schnitt 0,25 Sekunden Rechenzeit. Dann schafft der Prozessor grob 8 dynamische Anfragen pro Sekunde. Selbst wenn der Speicher 30 Worker zulässt, gerät der Prozessor oberhalb von 8 Anfragen pro Sekunde ins Schwitzen. Der Engpass ist hier also die CPU, nicht der RAM.

Wie Sie die Serverlast lesen, erklären wir ausführlich in unserem Artikel zur Load Average unter Linux. Prüfen Sie Ihre Rechnung anschließend auch mit dieser Kennzahl.

Rechenbeispiel: Wie viele Besucher verträgt mein Hosting?

Zunächst setzen wir alle Teile in einem Beispiel zusammen. Jede Zahl unten ist eine Annahme; setzen Sie für Ihre echte Website Ihre eigenen Daten ein.

Nach Littles Gesetz braucht diese Website in der Spitze im Mittel etwa 2 Worker. Anfragen kommen jedoch nicht in gleichen Abständen; manchmal ballen sie sich. Deshalb ist ein Puffer von einem Mehrfachen des errechneten Werts sinnvoll.

Nun die umgekehrte Sicht: Mit 8 Workern und 0,6 Sekunden mittlerer Antwortzeit liegt die theoretische Obergrenze bei rund 13 dynamischen Anfragen pro Sekunde. Bei 2 dynamischen Anfragen pro Seite entspricht das etwa 6,5 Seitenaufrufen pro Sekunde. Trotzdem sollten Sie das System nie an der Grenze betreiben; lassen Sie bequemen Spielraum.

Stellen Sie die Frage, wie viele Besucher verträgt mein Hosting, mit einer solchen Tabelle, dann ist die Antwort keine Werbezahl mehr. Stattdessen beruht sie auf Ihren eigenen Daten.

Wie berechnen Sie Bandbreite und monatlichen Datentransfer?

Neben Prozessor und Speicher hat die Kapazität auch eine Netzwerkseite. Dabei trennen Sie zunächst zwei Begriffe. Die Bandbreite ist die Datenmenge pro Sekunde, der monatliche Datentransfer dagegen die gesamte Datenmenge eines Monats.

Eine grobe Formel für den monatlichen Transfer:

Datentransfer pro Monat = mittleres Seitengewicht x Seitenaufrufe pro Monat

Rechenbeispiel: Bei einem mittleren Seitengewicht von 2 MB und 300.000 Seitenaufrufen im Monat ergibt sich ohne jeden Cache ein Transfer von rund 600 GB. Allerdings speichern wiederkehrende Besucher statische Dateien im Browsercache. Nutzen Sie ein CDN, liefert zudem meist das CDN die statischen Dateien aus, nicht Ihr Server. Folglich liegt der echte Wert in der Regel unter dieser groben Schätzung.

Für den momentanen Bandbreitenbedarf multiplizieren Sie die Seitenaufrufe pro Sekunde in der Spitze mit dem Seitengewicht. Komprimierte Bilder und weniger unnötige Skripte senken sowohl den Transfer als auch die Wartezeit der Nutzer.

Das ganze Thema behandeln wir in unserem Artikel zur Bandbreite beim Webhosting. In der Kapazitätsplanung ist die Bandbreite selten der erste Engpass. Bei Websites mit vielen Bildern oder Videos kann sie aber nach vorne rücken.

Woher bekommen Sie echte Messwerte?

Die Rechnung ist nur so gut wie die Daten darin. Sie beginnen mit Annahmen, sollten aber schnell zu gemessenen Werten wechseln. Dafür gibt es drei Hauptquellen.

1. Die Ansicht zur Ressourcennutzung im Hostingpanel: Bei Shared Hosting zeigt sie, wie nah Sie an die Grenzen für Prozessor, Speicher, I/O und Prozesse kommen. Name und Inhalt der Ansicht unterscheiden sich je nach Anbieter.
2. Analysetools: Hier finden Sie die stündliche Verteilung der Seitenaufrufe, Spitzenstunden und Kampagnentage.
3. Serverlogs: Sie halten fest, wann jede Anfrage kam, welche Adresse sie traf und, je nach Konfiguration, wie lange sie dauerte.

Diese drei Quellen ergänzen sich zudem gegenseitig. Die Webanalyse zeigt menschlichen Traffic, während Logs auch Bots, Crawler und Hintergrundaufrufe enthalten. Eine Stunde, die in der Analyse ruhig wirkt, zeigt in den Logs vielleicht starken Bottraffic, und genau das erklärt dann die Serverlast.

Um allgemeine Langsamkeit mit Ursachen auf dem Server zu verbinden, lesen Sie unseren Artikel Warum ist meine Website langsam. Dort betrachten wir den Zusammenhang zwischen TTFB, Datenbank und Ressourcengrenzen genauer.

Wie lesen Sie Antwortzeiten aus den Serverlogs?

Die mittlere Antwortzeit ist die wichtigste Eingabe für Littles Gesetz, und die Serverlogs liefern dafür den verlässlichsten Wert. Standardformate enthalten die Zeit oft nicht; deshalb erweitern Sie das Format.

Unter Nginx ergänzen Sie das Logformat um die Variable $request_time. Unter Apache schreibt der Formatcode %D die Dauer der Auslieferung in Mikrosekunden. Danach berechnen Sie die mittlere Dauer der dynamischen Anfragen in Ihrer Spitzenstunde.

log_format timed '$remote_addr [$time_local] "$request" $status $request_time';
access_log /var/log/nginx/example.com.access.log timed;

Bleiben Sie nicht beim Mittelwert stehen. Der langsame Rand, also die langsamsten 5 oder 1 Prozent der Anfragen, entscheidet darüber, ob eine Warteschlange entsteht. Liegt der Mittelwert bei 0,4 Sekunden, dauern einige Anfragen aber 5 Sekunden, dann blockieren genau diese langsamen Anfragen Ihre Worker.

Ist Ihnen das Lesen der Logs von Hand zu mühsam, gruppiert unsere Logfile Analyse Anfragen nach Statuscode, Adresse und Bottyp. So sehen Sie schnell, welche Seiten die meiste Last erzeugen.

Bei Shared Hosting dürfen Sie das Logformat oft nicht ändern. Arbeiten Sie dann mit den rohen Zugriffslogs Ihres Anbieters und fragen Sie dort nach Zeitdaten.

Wie prüfen Sie die Rechnung mit einem Lasttest?

Ein Lasttest schickt kontrollierten, künstlichen Traffic auf Ihre Website, damit Sie die Rechnung mit echten Ergebnissen vergleichen. Die Rechnung liefert eine Erwartung; der Lasttest zeigt, ob sie stimmt.

Ein einfaches Einstiegswerkzeug ist das Programm ab von Apache. Laut Apache Dokumentation legt -n die Gesamtzahl der Anfragen fest und -c die Zahl gleichzeitiger Anfragen. Die Dokumentation weist zudem darauf hin, dass ab HTTP/1.x nicht vollständig umsetzt. Unter Umständen misst es also eher seine eigene Leistung als die des Servers.

ab -n 500 -c 10 https://staging.example.com/

Halten Sie sich beim Lasttest an diese Regeln:

• Testen Sie eine Testkopie der Website statt der Livesite.
• Holen Sie bei Shared Hosting vorher die schriftliche Zustimmung Ihres Anbieters ein. Sonst wirkt der Traffic womöglich wie ein Angriff.
• Steigern Sie die Gleichzeitigkeit schrittweise und notieren Sie, wo die Antwortzeit springt.
• Testen Sie außerdem gecachte und ungecachte Seiten getrennt.

Der Punkt, an dem die Antwortzeit steil ansteigt, ist Ihre praktische Kapazität. Liegt er nahe an der errechneten Grenze, sind Ihre Annahmen stimmig.

Wie unterscheiden sich Shared Hosting und VPS bei der Kapazität?

Bei Shared Hosting teilen Sie die Ressourcen eines Servers mit anderen Konten, und der Anbieter begrenzt jedes Konto bei Prozessor, Speicher, Prozessen und I/O. Bei einem VPS stehen Ihnen eigene virtuelle Ressourcen zur Verfügung, und Sie verwalten die Konfiguration selbst.

Bei Shared Hosting ist die wichtigste Eingabe die Grenze für gleichzeitige Prozesse, die Ihr Anbieter Ihrem Konto gewährt. Dieser Wert hängt vom Tarif ab; lassen Sie ihn sich schriftlich nennen. Die Ressourcenlimits im Shared Hosting behandeln wir ausführlich in einem eigenen Artikel.

Die Unterschiede zwischen VPS und Cloud Server finden Sie in unserem Vergleich von VPS, VDS und Cloud Server.

Warum sollten Sie Besucherangaben in Hostingwerbung hinterfragen?

Auf Tarifseiten liest man oft, ein Paket sei „für Websites mit X Besuchern im Monat geeignet“. Solche Angaben geben eine grobe Richtung, doch die Annahmen dahinter stehen selten auf der Seite.

Welche Antwort ein Tarif auf die Frage gibt, wie viele Besucher verträgt mein Hosting, hängt von diesen Punkten ab:

• Geht die Schätzung von einer komplett gecachten Website aus oder von einem ungecachten Onlineshop?
• Unterstellt sie gleichmäßigen Traffic über den Monat, oder berücksichtigt sie Spitzenstunden?
• Welches mittlere Seitengewicht und wie viele dynamische Anfragen pro Seite setzt sie an?
• Wie hoch ist die Grenze für gleichzeitige Prozesse je Konto?

Ohne Antworten bleibt die Zahl daher ein grobes Werbesignal. Derselbe Tarif läuft bei einer schlichten Firmenwebsite bequem und gerät bei einem Shop mit starker Produktfilterung trotzdem ins Stocken.

Achten Sie bei der Tarifwahl deshalb auf technische Grenzen statt auf Besucherzahlen. Weitere Kriterien haben wir in unserem Ratgeber Webhosting auswählen gesammelt. Statt einzelne Anbieter zu loben oder zu kritisieren, konzentrieren Sie sich auf die richtigen Fragen.

Wann sollten Sie die Rechnung Ihrem Hostinganbieter überlassen?

Nicht jeder Websitebetreiber muss Worker einstellen oder Logformate ändern. Manchmal ist der beste Schritt, Daten zu sammeln und die Entscheidung dem Anbieter oder Ihrem technischen Team zu überlassen.

Bei Managed oder Shared Hosting haben Sie zum Beispiel keinen Zugriff auf die Einstellungen von FPM. Der Support des Anbieters kennt zudem die Grenzen Ihres Kontos besser als Sie. Ihre Aufgabe ist dann, Daten der Spitzenstunde und Fehlerzeitpunkte zu sammeln und weiterzugeben.

Ebenso gilt: Fehlt Ihnen Erfahrung in der Serveradministration, ändern Sie die Zahl der Worker auf einem VPS nicht nach Versuch und Irrtum. Ein falscher Wert kann den Speicher erschöpfen, und dann reagiert der ganze Server nicht mehr. Überlassen Sie solche Änderungen der Person, die den Server betreut.

Dennoch verschafft Ihnen das Verständnis der Rechnung einen Vorteil. Statt „die Website ist langsam“ sagen Sie Ihrem Anbieter: „In der Spitze kommen rund so viele dynamische Anfragen pro Sekunde, und wir stoßen an die Workergrenze.“ So bekommen Sie eine schnellere und treffendere Lösung. Brauchen Sie einen größeren Tarif, hilft Ihnen unsere Anleitung Hostingtarif ohne Ausfall upgraden.

Wie oft sollten Sie Ihren Kapazitätsplan aktualisieren?

Die Kapazitätsrechnung ist keine einmalige Aufgabe. Die Eingaben ändern sich, wenn die Website wächst, wenn Sie Plugins ergänzen oder wenn sich der Marketingkalender verschiebt.

Wir empfehlen eine neue Rechnung in diesen Situationen:

• Vor einer großen Kampagne, einer Rabattphase oder Fernsehwerbung.
• Nach einem neuen Theme, einem schweren Plugin oder einer neuen Zahlungsanbindung.
• Wenn der Traffic der Spitzenstunde in der Analyse spürbar steigt.
• Wenn die Antwortzeiten in den Logs zu klettern beginnen.

Bei Onlineshops wirkt sich diese Kontrolle direkt auf den Umsatz aus, denn eine Kasse, die in starken Momenten langsam wird, kostet Bestellungen. Möchten Sie Infrastruktur und Conversion Ihres Shops gemeinsam betrachten, gehört diese Analyse zu unserer E-Commerce Beratung.

Regelmäßige Aktualisierungen verringern außerdem Überraschungen. Somit gehen Sie in den nächsten großen Traffictag und wissen bereits, wo der Server an seine Grenzen kommt.

Zusammenfassung: Wie viele Besucher verträgt mein Hosting, Schritt für Schritt?

Die Antwort auf die Frage, wie viele Besucher verträgt mein Hosting, ergibt sich aus mehreren Messungen, nicht aus einer Zahl. Hier der Weg in Kurzform:

1. Finden Sie in der Webanalyse die Spitzenstunde und ihre Seitenaufrufe.
2. Berechnen Sie die Seitenaufrufe pro Sekunde und ergänzen Sie einen Spitzenfaktor.
3. Zählen Sie die dynamischen Anfragen pro Seite in den Entwicklertools des Browsers.
4. Messen Sie dann die mittlere Antwortzeit in den Logs.
5. Schätzen Sie mit Littles Gesetz den Bedarf an gleichzeitigen Workern.
6. Vergleichen Sie diesen Bedarf mit Prozessor, Arbeitsspeicher und Anbietergrenzen.
7. Bestätigen Sie das Ergebnis mit einem kontrollierten Lasttest.

Diese Schritte liefern Ihnen eine realistische Schätzung, keine Garantie. Trotzdem ist diese Schätzung nützlicher als die Besucherzahl auf einer Tarifseite, weil sie auf Ihrer Website und Ihrem Traffic beruht.