Shared Hosting: Unsichtbare Stolpersteine im Alltag
Shared Hosting klingt simpel. Schnell gebucht, kein Admin-Kram, Kosten überschaubar. Wer eine kleine Website, einen Shop oder Blog ins Netz bringen will, landet oft genau da. Anfangs läuft alles rund. Bis das erste Mal die Seite hängt – oder der Support freundlich, aber bestimmt drosselt. Kommt öfter vor, als viele denken.
Was bremst? Nicht nur Speicherplatz und Traffic. Die eigentlichen Stoppschilder sind oft inode, CPU, I/O und Entry Processes. Diese Limits stehen selten groß in der Werbung. Wer sie ignoriert, merkt es meist im falschen Moment – wenn nichts mehr geht.
inode-Limit: Dateichaos mit Ansage
Jede Datei, jedes Verzeichnis, jeder Symlink – alles verbraucht inodes. Viele Hoster deckeln das knallhart. 100.000 bis 400.000, manchmal auch weniger. Klingt viel? Für statische Seiten vielleicht. Aber: Ein paar WordPress-Plugins, Caching, nie gelöschte Logfiles, automatische Backups, und das Limit ist voll. Schnell.
Typisch: Upload verweigert. Website lädt nicht. Plugin zickt. Meldung: „Kein Speicherplatz“, aber die Platte ist halbleer. Ursache: inodes erschöpft. Passiert gerne am Wochenende.
Abhilfe? SSH und df -i, cPanel, oder was das Backend hergibt. Alte Caches und Logs weg. Backups ausmisten. Wer da nicht regelmäßig aufräumt, steht irgendwann im Regen. Und nein, „unendlich“ gibt’s bei Shared-Hostern nicht.
CPU-Limits: Wenn die Seite zum Dauerläufer wird
Echte CPU? Im Shared Hosting ein Märchen. Die Anbieter teilen brav auf – jeder kriegt ein Scheibchen pro Tarif. Meist kaum messbar: Sekundenbruchteile pro Minute. Wer drüber ist, wird ausgebremst oder gleich rausgeworfen. Klassiker: Prozesse killt der Hoster, Ladezeiten eskalieren, Seitenabbruch.
Warum? Plugins, Cronjobs, Traffic-Spitzen. WordPress mit 20 Erweiterungen, automatische Sicherungen: Da reicht schon Durchschnittsverkehr, und das Limit ist weg. Besucher braucht es gar nicht erst.
Monitoring? Oft ein Glücksspiel. Manchmal gibt’s Graphen im Backend, manchmal gar nichts. Dann bleibt nur eigenes Logging oder externe Tools. Ständig hohe Last? Skripte checken, Ballast raus. Und: Kein Plugin ist es wert, einen Hoster lahmzulegen.
I/O-Limits: Wenn die Festplatte hustet
I/O steht für Input/Output, klar. Gemeint: Festplattenzugriffe. Auch das wird reglementiert. Typisch: 2 MB/s, oder pro Minute eine fixe Anzahl Operationen. Wird meist erst auffällig, wenn’s knallt.
Was killt das I/O-Limit? Datenbanklast, viele gleichzeitige Dateioperationen, schlampig programmierte CMS, Backups im Minutentakt. Folge: Website wird langsam, Timeouts, Datenbankverbindungen sterben. Wer dann noch Debug-Logs anschaltet, macht’s nicht besser.
Gegenmittel: Caching aktivieren, Abfragen schlanker bauen, Backups nicht zur Hauptverkehrszeit starten. Wer größere Datenmengen schaufelt: Monitoring im Auge behalten – sofern der Anbieter überhaupt was anzeigt. Viele tun’s nicht.
Entry Processes: Der Flaschenhals für parallele Besucher
Entry Processes – klingt nach Geheimsprache. Gemeint: Wie viele PHP- oder CGI-Prozesse dürfen parallel starten? Typisch sind 10, 20, vielleicht 30. Klingt erst mal wenig. Für die private Seite reicht es oft. Aber: Bots, Plugins, Besucheransturm, langsame Skripte – schon ist Ende. Dann: HTTP 508, Seite weiß, Support meldet sich grinsend.
Gerade WordPress-Bastler kennen das. Viele Plugins, Hintergrundjobs, dazu Cron – schwupp, alle Prozesse belegt. Lösung? Prozesse kurz halten, Caching, Plugins aufräumen. Wer nicht weiß, was die Hälfte der installierten Plugins macht, kann mit Problemen rechnen.
Limits im Blick, Ärger vermeiden
Die meisten Hoster verstecken Limits im Kleingedruckten. Oder zeigen sie so kryptisch an, dass niemand durchblickt. Warnungen kommen spät, oft erst nach dem Absturz. Wer nicht warten will, bis die Seite stirbt, kontrolliert besser selber:
- inode-Anzahl: SSH (df -i), cPanel, was halt da ist
- CPU: Monitoring-Tools, eigene Logs bauen
- I/O: Falls sichtbar, regelmäßig draufschauen
- Entry Processes: Tools wie ps, Server-Panel, Logmeldungen
Wer hier dauernd an Grenzen stößt, sollte Tarif oder Anbieter wechseln. Anbieter, die Limits klar anzeigen, sind selten – aber Gold wert. Für größere Projekte: VPS oder Managed Server anschauen. Mehr Kontrolle, weniger Überraschung.
Fazit: Shared Hosting – günstig, aber launisch
Shared Hosting bleibt ein Kompromiss. Preiswert, schnell, aber die Limits bei inode, CPU, I/O und Entry Processes sind ständig im Hintergrund. Wer wächst, viele Plugins nutzt oder aufwändige Backups fährt, läuft Gefahr, ausgebremst zu werden.
Dauerhaft stabile Seiten brauchen Monitoring und gelegentliches Aufräumen. Wer keine Lust auf Fehlermeldungen und Support-Pingpong hat, sollte bei Problemen nicht kleckern, sondern den nächsten Hosting-Schritt gehen. Für Agenturen und Profis kann das die Nerven schonen – und am Ende den Kunden retten.
bye
mo
Anhänge
Zuletzt bearbeitet: