Warum Hosting-Tarife selten realistische Nutzerzahlen abbilden

Hosting-Tarife versprechen häufig Tausende gleichzeitige Nutzer, doch in der Praxis bremsen geteilte Ressourcen und Fair-Use-Regeln die Leistung deutlich. Ich zeige, warum Anbieter die Realität geschönter Nutzerzahlen ignorieren und wie Limits auf CPU, RAM und I/O echte Besucherströme ausbremsen.

Zentrale Punkte

• Shared-Limits: Geteilte Server drosseln Lastspitzen und erzeugen lange Ladezeiten.
• Fair Use: „Unbegrenzt“ kippt bei überdurchschnittlicher Nutzung in harte Begrenzungen.
• Performance-Mythos: Moderne Hardware ersetzt keine Optimierung und Isolation.
• Kostenfallen: Günstige Einstiegspreise führen bei Wachstum zu teuren Upgrades.
• Transparenz: Klare Angaben zu CPU-Shares, I/O und Burst sind entscheidend.

Warum Nutzerzahlen in Tarifen selten stimmen

Marketing verspricht große Zahlen, doch geteilte Server teilen ebenso die Leistung. Ein Nachbar-Account mit fehlerhaftem Code reicht, und deine Antwortzeit springt von unter 500 Millisekunden auf über 1000 Millisekunden. Ich habe erlebt, wie eine faire Nutzungsklausel das Tempo urplötzlich halbiert, obwohl die eigene Seite sauber optimiert war. Anbieter kalkulieren Durchschnittswerte, nicht echte Traffic-Peaks von Kampagnen, Medienerwähnungen oder Saisonalität. Wer wissen will, wie Versprechen entstehen, sollte sich über Overselling bei Webhosting informieren und die Annahmen hinter „unbegrenzt“ kritisch prüfen.

Fair-Use-Policy und geteilte Ressourcen

Ein Tarif mit „Traffic-Flat“ und viel Speicher klingt groß, doch Fair-Use bremst bei überdurchschnittlicher Nutzung. In Messungen sinkt die Conversion bei 5 Sekunden Ladezeit gegenüber 1 Sekunde um 64 Prozent, und Umsatz geht schmerzhaft verloren. Rechne das Beispiel: 1000 Besucher, 100 € Warenkorb, ein paar Sekunden mehr Wartezeit – am Monatsende fehlen schnell 19.700 €. Ein großzügiger Speicher von 52 GB hilft wenig, wenn CPU-Shares, Entry Processes oder I/O-Limits dich bei Last drosseln. Ich plane deshalb immer Obergrenzen für gleichzeitige Prozesse ein und schaue zuerst auf Limits, nicht auf plakative Marketingzahlen.

Der Performance-Mythos im Shared Hosting

Moderne CPUs und NVMe-SSDs klingen stark, doch ohne Isolierung gewinnt die Website keinen verlässlichen Durchsatz. Gute Anbieter setzen Limits für CPU, RAM und I/O, nur greifen diese unter Spitzenlast nicht immer schnell genug. Ich prüfe deshalb auch Entry Processes und max_execution_time, weil sie den Engpass in Stoßzeiten präzise markieren. Tools wie OPcache, Redis und serverseitiges Caching helfen spürbar, aber Nachbar-Last bleibt ein Risiko. Wer Drosselungen verstehen will, liest zuerst über Hosting-Drosselung verstehen und beobachtet reale Reaktionszeiten unter Last, nicht nur synthetische Benchmarks.

Versprechen von „Unbegrenzt“ im Realitätscheck

„Unbegrenzt“ bedeutet selten grenzenlose Ressourcen, vielmehr greift ein „praktisches Limit“, sobald Konten mehr als den Durchschnitt beanspruchen. CPU und RAM stellen die knappsten Güter in geteilten Umgebungen, und ein einzelner Container kann das Hostsystem belasten. Bei Überschreitung folgen Drosselungen, kurze Sperren oder automatische Prozess-Kills, oft ohne klare Rückmeldung. Zusatzkosten für SSL-Varianten, E-Mail-Zusätze oder erweiterte PHP-Optionen machen Einstiegspreise schnell hinfällig. Ich werte daher Nutzungsdaten monatlich aus und bewerte Limits härter als Marketing-Slogans zur Bandbreite.

Marketing vs. Realität im Shared Hosting

Werbeaussage	Verdecktes Limit	Auswirkung	Typischer Ausweg
Unbegrenzter Traffic	Fair-Use + I/O-Deckel	Throttle bei Peaks	Cache + CDN + VPS
Tausende Nutzer gleichzeitig	Entry Processes	503/Timeouts	Prozesslimit erhöhen
Unlimitierter Speicher	Inodes/Backup-Quota	Upload-Fehler	Entrümpeln/Upgrade
Schnell durch NVMe	CPU-Shares	Langsame PHP-Jobs	OPcache/Isolierung

Wer Zahlen richtig liest, plant Puffer für Lastspitzen und hält Exit-Optionen bereit, falls Limits früher greifen als gedacht. Ich setze auf messbare Grenzwerte wie IOPS, RAM pro Prozess und CPU-Zeit statt Show-Begriffen wie „Power“ oder „Turbo“. Entscheidend bleibt die Frage, wie viele gleichzeitige Requests der Tarif ohne Drosselung trägt. Ohne klare Angaben kalkuliere ich konservativ und teste parallel auf einem separaten Staging-System. So bleiben Kosten im Rahmen, während echte Besucher weiter flüssig bedient werden.

Was bedeuten Angaben wie „10.000 Besucher/Monat“?

Monatsangaben verschleiern Spitzen, denn Besucher kommen nicht linear, sondern in Wellen. Ein kurzer Peak bringt mehr gleichzeitige Requests als ein halber Tag Normalbetrieb. Fallen dann Entry Processes oder CPU-Shares zu klein aus, kippt die Seite binnen Sekunden in Timeouts. Ausfälle kosten pro Minute schnell fünfstellige Beträge, und verlorenes Vertrauen wirkt deutlich länger nach. Wer solche Risiken senken will, prüft Lastprofile und vermeidet Traffic falsch kalkulieren, bevor Kampagnen live gehen.

WordPress: Technik versus Tarif

HTTP/3, serverseitiges Caching und Bildkompression verkürzen Ladezeiten spürbar, doch harte Limits stoppen Spitzenlast trotzdem. Ein performanter Cache reduziert PHP-Aufrufe, während OPcache Skripte im Speicher hält. Redis entlastet Datenbankabfragen, allerdings nur, wenn CPU-Shares nicht bereits ausgelastet sind. Ich aktiviere erst Technik-Optimierungen, dann vermesse reale Concurrency, bevor ich auf einen größeren Plan umsteige. So bleibt klar, ob der Engpass am Code, an der Datenbank oder am Tarif liegt.

Wann ein Upgrade wirklich Sinn ergibt

Ein Wechsel zu VPS oder Dedicated lohnt, wenn gleichzeitige Nutzer regelmäßig an Entry-Process-Grenzen stoßen. Häufen sich 503-Fehler trotz Caching und schlankem Theme, fehlt Compute-Leistung, nicht „Traffic“. Ich beobachte CPU-Zeit pro Request, IOPS und Speicher pro PHP-Prozess über mehrere Tage. Bleibt die Kurve auch nachts hoch, skaliere ich horizontal über Cache/CDN oder vertikal über isolierte Ressourcen. Erst wenn Isolation garantiert ist, zahlt sich ein teureres Paket wirklich aus.

Praktische Kennzahlen verstehen und prüfen

Transparente Anbieter nennen CPU-Shares, I/O-Throughput, RAM pro Prozess und Burst-Handling als harte Werte. Ohne diese Angaben lässt sich die Tragfähigkeit nur schätzen, was Planung erschwert. Ich fordere konkrete Entry-Process-Zahlen und frage, wie viele gleichzeitige Requests der Stack wirklich schafft. Sinnvoll sind auch Zeitfenster: Drosselt der Hoster sofort oder erst nach 60 Sekunden Peak? Diese Details entscheiden, ob Kampagnen sauber laufen oder in Engpässen hängen bleiben.

Wie ich Kapazität realistisch berechne

Statt vager Nutzerzahlen rechne ich mit Concurrency und Antwortzeiten. Eine einfache Daumenregel: Maximale dynamische Requests pro Sekunde ≈ (gleichzeitige Prozesse) / (mittlere Serverzeit pro Request). Wenn ein Tarif 20 Entry Processes zulässt und ein dynamischer Request 300 ms Serverzeit braucht, liegen theoretisch ~66 RPS drin – wohlgemerkt nur, solange CPU, RAM und I/O nicht limitieren. Realistisch ziehe ich 30–50 Prozent Sicherheitsmarge ab, weil Cache-Misses, langsame Queries und PHP-Startkosten streuen.

• Worst-Case: Rechne ohne Cache und mit p95-Latenz, nicht mit dem Mittelwert.
• Best-Case: Hohe Cache-Hitrate, statische Auslieferung, CDN aktiv – dann zählen eher I/O und Netzwerk.
• Gemischt: 80/20-Regel (80 % gecacht, 20 % dynamisch) bildet viele Shops und Blogs gut ab.

Entscheidend ist die Verweilzeit eines Requests im Stack: Ein Checkout mit 1,2 s Serverzeit verdrängt sechs schnellere Blog-Requests. Darum teste ich Szenarien getrennt (Katalog, Suche, Warenkorb, Checkout) statt alles zu mitteln. Nur so erkenne ich, wo der Flaschenhals zuerst reißt.

Lasttests: So messe ich echte Tragfähigkeit

Ich plane strukturierte Lasttests, weil synthetische „Peak-Messungen“ oft in die Irre führen. Vorgehen, das sich bewährt hat:

• Aufwärmen: Cache füllen, OPcache auf Temperatur bringen, 5–10 Minuten Traffic mit niedriger Rate.
• Rampen: In 1–2-Minuten-Schritten von z. B. 10 auf 200 virtuelle Nutzer hochfahren, nicht sprunghaft.
• Mix: Anteil loginsensitiver Seiten (nicht gecacht) realistisch einbeziehen, z. B. 20–40 %.
• Messen: p50/p95/p99, Fehlerquote (5xx/Timeouts), Queue-Länge/Backlog, CPU-Steal, iowait.
• Stabilität: 10–15 Minuten auf Plateau halten, um Drosselmechanismen (Fair-Use) zu triggern.

Wichtig: Tools liefern unterschiedliche Zahlen. Ich gleiche Synthetics (künstlicher Lasttest) mit RUM-Daten (echtes Nutzerverhalten) ab. Springen p95-Werte nur bei echten Nutzern, klemmt meist die Datenbank oder externes API – nicht das Webserver-Frontend.

Cache-Hitrate und eingeloggte Nutzer

Shared-Tarife leben von einer hohen Cache-Hitrate. WordPress umgeht den Seiten-Cache bei eingeloggten Nutzern, im Warenkorb und oft bei WooCommerce-Elementen. Zielwerte, die ich ansetze:

• Öffentlicher Blog/Magazin: 90–98 % Cache-Hitrate erreichbar.
• Shop: 70–90 % je nach Anteil eingeloggter Nutzer und Personalisierung.
• Community/SaaS: 30–70 %, Fokus auf Objekt-Cache und Datenbankoptimierung.

Hilfreich sind Fragment-Caching (nur Blöcke regenerieren), Preloading/Jetzt-vorwärmen nach Deployments und kurze, aber sinnvolle TTLs. Ich beobachte, ob Cookies oder Query-Parameter den Cache ungewollt bypassen. Schon kleine Regeln (kein Cache bei bestimmten Parametern, vereinheitlichte URLs) erhöhen die Hitrate und entlasten CPU und I/O massiv.

Typische versteckte Bremsen im Alltag

Neben offensichtlichen Limits wirken im Shared-Betrieb viele kleine Bremsen kumulativ:

• Cron-Jobs und Backups: Serverweite Virenscans oder Snapshot-Fenster erhöhen I/O-Latenz – plane eigene Media- oder Feed-Generierungen außerhalb dieser Zeiten.
• Bild- und PDF-Verarbeitung: On-the-fly-Generierung frisst RAM und CPU. Besser vorgenerieren (Build-Prozess, Queue) und Last entkoppeln.
• Externe APIs: Langsame Drittanbieter verketten die Antwortzeit. Mit Timeouts, Circuit Breakern und asynchronen Queues entkoppeln.
• Datenbank-Nadelöhre: Fehlende Indizes, „LIKE %…%“-Suchen und N+1-Abfragen treffen I/O-Limits früher als gedacht.
• Bot-Traffic: Crawler erhöhen Last ohne Umsatz. Rate-Limiting und aggressive Caching-Regeln reduzieren den Schaden.

Ich prüfe regelmäßig Slow-Logs, identifiziere wiederkehrende Peaks (z. B. stündliche Exporte) und verteile sie auf Nebenzeiten. Viele „mysteriöse“ Einbrüche erklären sich durch kollidierende Hintergrundjobs.

Monitoring und Alarmierung in der Praxis

Performance schützt man wie Verfügbarkeit: mit klaren Schwellen und Alarmen. Ich setze SLOs für TTFB p95 (z. B. < 600 ms für Cache-Hits, < 1200 ms für dynamische Seiten), Fehlerquote (≤ 1 % 5xx), und Ressourcen (CPU-Steal < 5 %, iowait < 10 %). Alarme müssen früh anschlagen, bevor Fair-Use Drosseln greift.

• Servermetriken: CPU (User/System/Steal), RAM/Swap, I/O (IOPS, MB/s, iowait), Open Files/Prozesse.
• PHP-FPM: aktive/warteende Worker, max_children-Hitrate, Request-Dauer-Verteilung.
• Datenbank: langsame Queries, Verbindungszahl, Buffer-Pool-Hitrate, Locks.
• Anwendungsmetriken: Cache-Hitrate, Queue-Länge, 95./99. Perzentile je Endpoint.

Ohne diese Sicht läuft man „blind“. Shared-Umgebungen verzeihen das selten, weil Headroom klein ist und Drosselung abrupt kommt.

Migrationspfade und Kostenplanung

Ich plane von Anfang an eine Exit-Strategie, damit Wachstum nicht im Chaos endet. Drei typische Pfade:

• Besser isolierter Shared-Plan: Höhere Entry-Process-Limits, eigene CPU-Shares, priorisierte I/O – geeignet für moderate Peaks.
• Managed WordPress/Stack: Spezifische Optimierungen (Object-Cache, Bildverarbeitung, CDN-Integration). Achtung auf Feature-Limits und Zusatzkosten.
• VPS/Dedicated: Volle Isolation, dafür mehr Pflegeaufwand oder Management-Aufpreis. Lohnt, wenn p95-Latenzen trotz Optimierung hoch bleiben.

Kosten kippen oft durch Nebenthemen: zusätzliche Staging-Umgebungen, E-Mail-Zustellung mit Reputation, erweiterte Backups, mehr PHP-Worker. Ich reserviere 20–30 % Budget als Puffer für Wachstum und unvermeidliche Lastschwankungen. So bleibt der Wechsel planbar, statt in einem Notumzug zu enden.

Checkliste vor Vertragsabschluss

Diese Fragen kläre ich mit Anbietern, bevor ich unterschreibe:

• CPU: Wie viele vCores/Prozentshares sind garantiert? Wie wird „Burst“ definiert?
• Prozesse: Konkrete Zahlen zu Entry Processes, PHP-FPM-Worker und NPROC-Limits?
• I/O: IOPS- und MB/s-Deckel, getrennt für Lesen/Schreiben? Wie werden große Dateien behandelt?
• Datenbank: max_user_connections, Query-Limits, Speicher für temporäre Tabellen?
• Drossel-Zeitfenster: Greift Fair-Use sofort oder nach definierter Dauer? Wie lange hält die Drossel an?
• Backups: Häufigkeit, Aufbewahrung, Restore-Dauer – und in welchem Zeitfenster laufen System-Backups?
• Isolierung: Container/Limits pro Account? Schutz vor „Noisy Neighbors“?
• Transparenz: Zugriff auf Logs, Metriken, PHP-FPM-Status, Error-Logs ohne Support-Ticket?
• Staging/Deploy: Gibt es Staging-Kopien, Rollbacks, sichere Deploy-Optionen?

Wer diese Punkte sauber geklärt hat, erlebt seltener böse Überraschungen – und kann Performanceziele belastbar zusagen.

Bots, Crawler und der Unterschied zwischen „Traffic“ und „Nutzern“

In Shared-Umgebungen zählt nicht nur die Menge an Requests, sondern deren Qualität. Aggressive Crawler, Preisbots oder Monitoring-Agenten erzeugen viel Last ohne Wert. Ich:

• Rate-Limite automatisierte Zugriffe serverseitig, statt sie auf Anwendungsebene zu blocken.
• Cache statische Assets großzügig, reduziere Varianten und setze konsistente Cache-Keys.
• Priorisiere menschliche Zugriffe, indem ich besonders teure Endpunkte (Suche, Reports) absichere.

Viele „10.000 Besucher“ entpuppen sich als 60 % Bots. Wer echte Nutzer trennt, schöpft Ressourcen für zahlende Kunden statt für Crawler ab.

Datenbank und PHP: kleine Stellschrauben, große Wirkung

Shared-Hosting verzeiht keine ineffizienten Zugriffe. Zwei Maßnahmen tragen überproportional:

• Index-Hygiene: Häufige Filterfelder indizieren, JOINs vereinfachen, EXPLAIN regelmäßig prüfen. Ein Index spart schnell 10–100 ms pro Request.
• PHP-Arbeitsspeicher: Realistische memory_limit-Werte pro Prozess und OPcache-Größe anpassen. Zu knapp – viele Compiles; zu groß – frühes Out-of-Memory.

Ich betrachte p95-Speicher je PHP-Prozess und rechne hoch auf die maximale Workerzahl. Wenn das Ergebnis nahe am RAM-Limit liegt, drohen OOM-Kills oder harte Drosseln – unabhängig von „unbegrenztem“ Traffic.

Kurze Fallstudien aus der Praxis

Ein Blogartikel ging viral, doch der Tarif mit „Traffic-Flat“ war nach Minuten an Grenzen, weil Entry Processes knapp waren. Ein kleiner Shop sah langsame Kasse bei Flash-Sales, obwohl Seiten-Cache aktiv war; die Datenbank starb an I/O-Deckeln. Eine Portfolio-Seite blieb schnell, bis ein Nachbar-Account Backups im Takt startete und die Antwortzeiten verdoppelte. Ein SaaS-Formular kippte in Timeouts, da max_execution_time zu streng gesetzt war und Requests abbrach. Ein Wechsel auf isolierte Ressourcen plus behutsame Optimierungen löste alle fünf Fälle, ohne die Architektur zu verkomplizieren.

Zusammenfassung und klare Schritte

Überhöhte Nutzerzahlen in Tarifen ignorieren geteilte Ressourcen, Fair-Use-Regeln und harte Limits. Wer verlässlich skaliert, prüft Entry Processes, CPU-Shares, I/O und RAM pro Prozess vor Vertragsabschluss. Ich setze zuerst auf Caching, OPcache, Bildoptimierung und ggf. Redis, messe dann Lastspitzen mit realen Szenarien. Anschließend entscheide ich zwischen besser isoliertem Shared-Plan, VPS oder Dedicated, abhängig von gleichzeitigen Requests und Fehlerquote. So liefern Hosting-Tarife echten Gegenwert, statt bei Wachstum in teure Überraschungen zu führen.