Shared Hosting: Wann schnelle CPUs trotz geringer Kernzahl helfen

Kerne, Threads und CPU-Zeit unterscheiden

Ein physischer Kern ist eine Recheneinheit des Prozessors. Das Betriebssystem sieht dagegen logische Prozessoren als ausführbare Einheiten: Bei gleichzeitigem Multithreading können mehrere davon Ressourcen eines physischen Kerns teilen. Ihre Anzahl lässt deshalb nicht unmittelbar erkennen, wie viele voneinander unabhängige Kerne für einen Hosting-Account verfügbar sind.

Im Shared Hosting teilen sich mehrere Accounts die Hardware eines Servers. Ein Tarif kann begrenzen, wie viel CPU-Zeit die Prozesse eines Accounts innerhalb eines Zeitraums verbrauchen dürfen. Dieses CPU-Zeitbudget ist etwas anderes als die Zusage, einen physischen Kern exklusiv zu nutzen. Linux-cgroups sind eine mögliche technische Grundlage für solche Grenzen, aber nicht die einzig mögliche Umsetzung.

Steht im Tarif etwa „ein vCore“ oder „100 Prozent CPU“, solltest du die Definition des Anbieters prüfen. Die Angabe kann ein Rechenzeitbudget beschreiben, ohne einen bestimmten Kern dauerhaft zu reservieren. Auch aus der gesamten Kernzahl des Hostservers folgt nicht, wie viel Leistung ein einzelner Account tatsächlich gleichzeitig nutzen darf.

Gleichzeitigkeit bezeichnet hier, wie viele Anfragen oder Prozesse parallel bearbeitet werden können. Sie hängt unter anderem von Prozesslimits, Speicher und verfügbarem CPU-Budget ab. CloudLinux kann dafür eigene Ressourcenlimits einsetzen; ob ein Tarif diese Technik verwendet und wie sie konfiguriert ist, musst du beim Anbieter erfragen.

Ressourcenbegrenzung und Sicherheitsisolation erfüllen unterschiedliche Aufgaben: Ein Limit steuert den Verbrauch, während eine Isolation den Zugriff zwischen Umgebungen einschränken soll. Die Einordnung von CloudLinux Site Isolation und CageFS erklärt entsprechende Sicherheitsmechanismen; daraus folgt für sich genommen keine bestimmte CPU-Zuteilung.

Warum GHz allein nicht entscheiden

Die Taktfrequenz gibt an, wie viele Taktzyklen ein Prozessor pro Sekunde ausführt. Ein höherer Takt kann CPU-gebundene Arbeit beschleunigen, sagt aber allein nicht, wie viel eine Website davon hat. Unterschiedliche Prozessorarchitekturen erledigen pro Takt unterschiedlich viel Arbeit; auch der konkrete Programmcode beeinflusst das Ergebnis.

Zur Single-Core-Leistung tragen außerdem Cache und Speicherverhalten bei. Muss ein Prozess häufig auf Daten warten, kann eine höhere Frequenz weniger bewirken als bei einer Berechnung, deren Daten bereits schnell verfügbar sind. Ein Vergleich nur nach GHz blendet diese Unterschiede aus und ersetzt keinen anwendungsbezogenen Benchmark.

Ein begrenztes Datenblattbeispiel ist der AMD EPYC 4564P: Für dieses Modell nennt AMD 16 Kerne, 32 Threads, 4,5 GHz Basistakt und bis zu 5,7 GHz maximalen Boost. Diese Angaben beschreiben den Prozessor, nicht die Leistung eines bestimmten Hosting-Tarifs.

Der Maximalboost ist weder ein zugesicherter Dauerwert noch die Frequenz, die jederzeit auf allen Kernen anliegt. Ebenso wenig zeigen die Produktdaten, wie schnell ein bestimmter Shared-Hosting-Tarif eine WordPress- oder PHP-Anfrage bearbeitet. Dafür spielen neben der Hardware auch Konfiguration, Auslastung und Tarifgrenzen eine Rolle.

Wenn Anbieter mit high frequency cpu hosting werben, frage deshalb nach dem konkreten Prozessormodell und dem verfügbaren Ressourcenbudget. Aussagekräftige Leistungsvergleiche benötigen zusätzlich Angaben zur Softwareversion, Serverkonfiguration, Arbeitslast und zu den Testbedingungen. Ohne diese Angaben lässt sich ein beworbener GHz-Wert nicht zuverlässig in eine kürzere Antwortzeit übersetzen.

PHP-Anfragen und parallele Verarbeitung

Bei einer typischen synchronen Anfrage verarbeitet ein PHP-Worker die einzelnen Schritte seiner PHP-Arbeit überwiegend nacheinander. Eine schnellere CPU kann diesen Teil verkürzen, wenn er tatsächlich rechenintensiv ist. Wartet der Worker dagegen vor allem auf eine Datenbank oder einen externen Dienst, bleibt der Nutzen höherer Prozessorleistung für diese Wartezeit begrenzt.

Die Suchformulierung php single core bedeutet deshalb nicht, dass eine gesamte Website nur einen Kern verwenden kann. Mehrere Anfragen können von mehreren Workern parallel bearbeitet werden; auch Webserver und Datenbank können gleichzeitig arbeiten. Entscheidend ist, wie viel dieser parallelen Arbeit die verfügbaren Ressourcen und die jeweilige Konfiguration zulassen.

Bei PHP-FPM begrenzt pm.max_children die Zahl der gleichzeitig bedienten Anfragen eines Pools. Ist die Grenze erreicht, können zusätzliche Anfragen nicht sofort von einem weiteren Worker dieses Pools bearbeitet werden. Das Limit ist jedoch keine Aussage darüber, wie viele Besucher insgesamt eine Website nutzen können.

Die Prozessverwaltung von PHP-FPM kennt drei Betriebsarten: static hält eine feste Zahl von Workern vor. dynamic passt ihre Zahl anhand der Konfiguration an die Nachfrage an; ondemand startet Worker bei Bedarf. Die gewählte Betriebsart bestimmt damit auch, wann Prozesse bereitstehen oder neu gestartet werden.

Mehr Worker schaffen nicht automatisch mehr CPU-Zeit. Sie benötigen außerdem Arbeitsspeicher und können bei paralleler Ausführung gemeinsam an ein Account-Limit stoßen. Für die Beurteilung einer shared hosting cpu gehören daher Worker-Zahl und Ressourcenbudget zusammen. Nicht jeder Tarif verwendet PHP-FPM oder erlaubt Kunden, dessen Einstellungen selbst zu ändern.

CPU-Quota bei paralleler Last

Eine CPU-Quota legt fest, wie viel Rechenzeit eine Prozessgruppe innerhalb eines Zeitraums verbrauchen darf. Unter Linux cgroup v2 beschreibt cpu.max dieses Budget und die zugehörige Periode. Die Quote reserviert damit nicht automatisch einen exklusiven physischen Kern: Sie begrenzt die insgesamt verfügbare CPU-Zeit der Gruppe.

Illustratives Rechenbeispiel, keine Messung: Eine Gruppe erhält 100 Millisekunden CPU-Zeit pro 100 Millisekunden Periode. Das entspricht im Mittel der Rechenzeit eines vollständig ausgelasteten logischen Prozessors. Rechnen zwei Prozesse gleichzeitig auf zwei verfügbaren logischen Prozessoren, können sie das gemeinsame Budget theoretisch nach etwa 50 Millisekunden Wandzeit verbrauchen.

Ist das Budget ausgeschöpft, können die Prozesse bis zur nächsten Periode gedrosselt werden. Die beiden Worker besitzen also nicht jeweils ein eigenes Budget von 100 Millisekunden. Ob und wann sie tatsächlich parallel laufen, hängt unter anderem vom Scheduler, den verfügbaren CPUs und ihrem Verhalten ab; das Beispiel sagt keine konkrete Antwortzeit voraus.

Für die Untersuchung stellt cgroup v2 in cpu.stat unter anderem Zähler zur Drosselung bereit. Steigen sie während einer repräsentativen Lastphase, ist das ein Hinweis auf eine ausgeschöpfte Quote. Ein einzelner Zählerstand erklärt jedoch noch nicht, welche Anfrage betroffen war oder ob daneben weitere Engpässe bestehen.

Ob diese Dateien im Tarif zugänglich und für die Website relevant sind, musst du mit dem Anbieter klären. Shared Hosting kann andere Mechanismen einsetzen: CloudLinux dokumentiert beispielsweise eigene LVE-Limits für CPU und weitere Ressourcen. Aus dem Linux-Beispiel lässt sich deshalb weder die konkrete Konfiguration noch das Verhalten jedes Hosting-Accounts ableiten.

CMS, Shop und Hintergrundjobs

Bei einer ungecachten CMS-Seite führt der Server für den Aufruf Anwendungslogik aus und beschafft benötigte Daten. Entfällt ein großer Teil der Bearbeitung auf CPU-Arbeit, kann eine höhere Leistung pro Kern diesen Abschnitt verkürzen. Das gilt etwa für aufwendige Berechnungen im PHP-Code, nicht automatisch für die gesamte Zeit bis zur fertigen Seite.

Wartet dieselbe Anfrage dagegen überwiegend auf eine Datenbankabfrage oder eine externe API, kann der PHP-Prozess in dieser Zeit nur begrenzt von einer schnelleren CPU profitieren. Für die Entscheidung zählt daher die Aufteilung der serverseitigen Antwortzeit: Wie viel wird gerechnet, und wie viel entfällt auf das Warten auf andere Dienste?

Ein Shop zeigt, warum diese Frage für unterschiedliche Seiten verschieden ausfallen kann. Öffentliche Produktseiten lassen sich unter passenden Bedingungen als fertige Antwort zwischenspeichern. Ein Cache-Treffer kann die erneute vollständige PHP-Verarbeitung vermeiden; Warenkorb und Checkout müssen dagegen häufig individuelle Daten berücksichtigen und bleiben dynamisch.

Viele gleichzeitige Checkout-Anfragen können deshalb Worker oder CPU-Budget stärker beanspruchen als ebenso viele Aufrufe gecachter Seiten. Besucherzahlen allein beschreiben diese Last nicht: Entscheidend ist, welche Endpunkte gleichzeitig angefordert werden und wie oft der Cache greift. Bei PHP-FPM begrenzt zudem die Pool-Einstellung pm.max_children die Zahl gleichzeitig bedienter Anfragen.

Ein rechenintensiver Import im Backend kann wiederum von schneller Einzelarbeit profitieren. Läuft er parallel zu Besucheranfragen, konkurrieren die Prozesse möglicherweise um dasselbe CPU-Zeitbudget. Ob ein Cronjob oder Import tatsächlich derselben begrenzten Gruppe zugeordnet ist, hängt vom Tarif und seiner Einrichtung ab; frage vor einer Kapazitätsentscheidung beim Anbieter nach.

Für einen aussagekräftigen Vergleich solltest du diese Arbeitslasten getrennt betrachten: eine typische dynamische Anfrage, eine Phase mit mehreren gleichzeitigen Anfragen und gegebenenfalls den Import während des laufenden Betriebs. So erkennst du eher, ob die Geschwindigkeit eines einzelnen Arbeitsschritts oder die verfügbare Gesamtkapazität die wichtigere Stellschraube ist.

Beobachtungen und Engpässe vergleichen

Eine langsame Antwort benennt noch keine Ursache. Die folgende Übersicht verbindet typische Beobachtungen mit prüfbaren Möglichkeiten. Sie berücksichtigt insbesondere CPU-Zeitlimits, die bei PHP-FPM begrenzte Worker-Zahl und den Unterschied zwischen gespeichertem PHP-Code und einer bereits erzeugten Antwort.

Jede Tabellenzeile ist eine Hypothese, keine fertige Diagnose. Langsame Antworten unter Parallelität können beispielsweise mit einer CPU-Drosselung zusammenfallen, aber auch durch belegte Worker oder eine wartende Datenbank entstehen. Prüfe deshalb möglichst mehrere Signale zur selben Zeit und für dieselbe Arbeitslast, statt aus einem einzelnen Symptom den Tarifwechsel abzuleiten.

Trenne bei der Auswertung die Antwortzeit einer Anfrage vom Durchsatz: Eine schnellere einzelne Antwort bedeutet nicht automatisch, dass bei hoher Gleichzeitigkeit entsprechend mehr Anfragen pro Sekunde verarbeitet werden. Umgekehrt kann ein System einen guten Durchsatz erzielen und einzelne Anfragen dennoch länger warten lassen.

Auch die wahrgenommene Seitenladezeit ist nicht mit der serverseitigen Antwortzeit gleichzusetzen. Nach der Antwort können beispielsweise weitere Ressourcen geladen und im Browser verarbeitet werden. Ein CPU-Upgrade im Hosting adressiert nur den betroffenen serverseitigen Anteil; für einen fairen Vergleich sollten Cache-Zustand, angefragte Seite und Parallelität gleich bleiben.

Beim Cache lohnt außerdem die begriffliche Trennung: OPcache speichert kompilierten PHP-Code und kann damit erneute Kompilierung vermeiden. Ein Seitencache hält dagegen eine erzeugte Antwort vor. Ein schneller Cache-Treffer beweist daher weder, dass dynamische Anfragen ausreichend CPU-Budget haben, noch dass OPcache ihre Anwendungslogik ersetzt.

Drosselung und Wartezeiten erkennen

Beginne die Diagnose mit Anfragen, die für deine Website typisch sind: etwa eine öffentliche CMS-Seite, eine Suche und bei einem Shop den Checkout. Halte fest, ob die jeweilige Antwort aus dem Seitencache stammt. Vergleiche anschließend einzelne Aufrufe und eine für dein Projekt repräsentative Zahl gleichzeitiger Anfragen, statt allein die Gesamtzahl der Besucher zu betrachten.

Trenne möglichst die CPU-Zeit der Anwendung von der gesamten Antwortzeit und den Wartezeiten auf Datenbank oder externe Dienste. Ist der CPU-Anteil klein, kann ein schnellerer Prozessor nur einen entsprechend begrenzten Teil des Aufrufs verkürzen. Fehlen dir geeignete Messwerte, frage den Anbieter nach verfügbaren Logs, Metriken oder einer geeigneten Auswertung.

Untersuche bei paralleler Last, ob verfügbare Worker ausgelastet sind und ob Limitzähler ansteigen. Bei PHP-FPM begrenzt pm.max_children die gleichzeitig bedienten Anfragen eines Pools; ob du diesen Wert oder die Auslastung sehen kannst, hängt vom Tarif ab. Linux-cgroup-v2-Systeme können in cpu.stat unter anderem Drosselungszähler ausweisen. Ein steigender Zähler ist ein Anlass, das CPU-Budget und den Messzeitraum genauer zu prüfen.

Falls SSH und die betreffende Datei zugänglich sind, zeigt cat /proc/self/cgroup die cgroup-Zuordnung des aufrufenden Prozesses. Daraus folgt nicht, dass Webanfragen in derselben Gruppe laufen. Kläre Pfade, Rechte und Interpretation mit dem Anbieter; auch Fehlercodes lassen sich nicht pauschal einem bestimmten Limit jedes Shared-Hosting-Systems zuordnen.

Cache prüfen und Tarife vergleichen

Prüfe zuerst, welche öffentlichen Seiten sicher als vollständige Antwort zwischengespeichert werden können. Ein Seitencache kann wiederholte dynamische Verarbeitung bei einem Treffer vermeiden. Personalisierte Inhalte, Warenkorb und Checkout benötigen dagegen eine passende Cache-Strategie, damit Besucher keine fremden oder veralteten Daten erhalten.

Ein anderer Ansatz ist, die Arbeit bei Cache-Misses zu verringern: Untersuche langsame Datenbankabfragen und entferne unnötige dynamische Verarbeitung. Bei einem externen Dienst kann dessen Antwortzeit entscheidend sein; dann solltest du zunächst diesen Aufruf betrachten, statt die CPU als Ursache vorauszusetzen. Welche Änderung hilft, hängt vom tatsächlich langsamen Pfad ab.

Davon zu unterscheiden ist OPcache: Er speichert kompilierten PHP-Code, ersetzt aber weder einen vollständigen Seitencache noch die Ausführung der Anwendungslogik. Prüfe Verfügbarkeit und Einstellungen in der Web-Laufzeitumgebung. Die CLI besitzt eine eigene OPcache-Einstellung; ein Blick auf die Kommandozeile allein belegt daher nicht die Konfiguration für Webanfragen.

Für einen Tarifvergleich solltest du dieselben Anfragen mit gleichen Softwareversionen, vergleichbarem Datenbestand und festgehaltenem Cache-Zustand gegenüberstellen. Wiederhole den Vergleich bei derselben Parallelität und berücksichtige die jeweils verfügbaren CPU-, Worker- und Speicherbudgets. Andernfalls kann ein Unterschied durch die Testbedingungen entstehen, ohne etwas Verlässliches über die Prozessorleistung auszusagen.

Halte außerdem getrennt fest, wie lange einzelne Antworten dauern und wie viele Anfragen in einem Zeitraum bearbeitet werden. Ein Tarif kann für einen einzelnen Aufruf günstig erscheinen und bei gleichzeitiger Last dennoch an Grenzen stoßen. Werte aus einem Vergleich gelten zunächst nur für die untersuchte Anwendung und ihre Bedingungen.

Schnellere CPU oder mehr Budget?

Wenn eine repräsentative dynamische Anfrage überwiegend CPU-Arbeit verrichtet und weder Worker noch Speicher oder Zeitbudget begrenzen, ist höhere Pro-Kern-Leistung eine plausible Tarifoption. Sie kann den rechnenden Teil der Einzelanfrage verkürzen. Wie stark sich das auf die gesamte Antwort auswirkt, hängt aber weiterhin von der Anwendung und ihren Wartezeiten ab.

Zeigen die Daten dagegen Drosselung oder ausgeschöpfte Worker bei mehreren gleichzeitigen Anfragen, prüfe ein größeres Ressourcenbudget. Mehr CPU-Zeit kann bei einer belegten Quota-Grenze helfen; zusätzliche Worker benötigen zugleich ausreichend Speicher und Rechenzeit. Sind Datenbank oder externe Dienste der Engpass, ist ein höheres CPU-Budget allein keine verlässliche Lösung.

Vor einem Wechsel lohnt sich der Vergleich mit der Optimierung der bestehenden Installation. Ein geeigneter Seitencache oder eine verbesserte Abfrage kann dynamische Arbeit reduzieren, ohne dass du sofort einen größeren Tarif benötigst. Wiederhole die Diagnose nach einer Änderung unter vergleichbaren Bedingungen, damit du ihre Wirkung von anderen Einflüssen unterscheiden kannst.

Ein VPS als Alternative zum Shared Hosting bietet meist mehr Einfluss auf Software und Konfiguration, bringt aber auch mehr Verantwortung für Sicherheit, Updates und Kapazitätsplanung mit. Virtuelle CPUs sind ohne ausdrückliche Anbieterzusage keine exklusiven physischen Kerne. Prüfe deshalb auch dort die konkrete Ressourcenzuteilung und die Vertragsbedingungen.

Frage den Anbieter vor der Entscheidung nach dem Prozessormodell, der Definition des CPU-Zeitbudgets und dem Umgang mit Lastspitzen. Kläre außerdem, welche Worker- und Speichergrenzen gelten, ob Hintergrundjobs dasselbe Budget teilen und welche Limitzähler du einsehen kannst. Erst diese Angaben machen eine beworbene CPU-Leistung für deinen konkreten Tarif einordbar.