AMD EPYC oder Intel Xeon: Die richtige Plattform für Webhosting wählen

Hosting-Profile vor dem CPU-Vergleich

Webhosting ist kein einheitlicher CPU-Workload. Eine Plattform für tausende kleine Accounts folgt anderen Regeln als ein Knoten für virtuelle Maschinen oder ein Datenbankserver. Vor dem Vergleich von AMD EPYC und Intel Xeon sollten deshalb Anfrageprofil, Zahl gleichzeitig aktiver Mandanten, RAM-Bedarf, Storage-I/O und akzeptierte Antwortzeiten feststehen. Erst diese Kombination macht technische Daten einer CPU für die Beschaffung aussagekräftig.

Shared Hosting verarbeitet viele voneinander unabhängige PHP-, CMS- und E-Mail-Aufgaben mit oft kurzen Lastspitzen. Hohe Kerndichte kann helfen, doch wirksame Grenzen für CPU-Zeit, Prozesse, Arbeitsspeicher und I/O sind ebenso wichtig. Ohne solche Limits kann ein einzelner Account knappe Ressourcen belegen und die Antwortzeiten anderer Kunden verschlechtern. Planbare Mandantentrennung zählt hier häufig mehr als ein Spitzenwert in einem synthetischen Multicore-Test.

Bei Managed CMS und Shops sind die Anforderungen gemischter. Dynamische PHP-Requests, Objektcache, Datenbankabfragen, Cronjobs und Verwaltungszugriffe treffen zeitweise gleichzeitig ein. Für wenige anspruchsvolle Anwendungen kann Leistung pro Kern wichtiger sein als die maximale Kernzahl; bei dauerhaft vielen unabhängigen PHP-FPM-Workern gewinnt dagegen Parallelität an Gewicht. Entscheidend bleibt, ob Webserver, PHP-Prozesse und Datenbank passend dimensioniert sind.

Ein WooCommerce-Shop verdeutlicht die Trennung: Statische Produktbilder kann ein Webserver mit Cache sehr effizient ausliefern. Warenkorb, Checkout und Lagerbestand erzeugen jedoch personalisierte PHP-Ausführung und Datenbankzugriffe. Mehr CPU-Kerne beseitigen keine Wartezeit, wenn Abfragen Indizes vermissen, der Buffer Pool zu klein ist oder die NVMe-Latenz unter Last steigt. Deshalb sollten Request-Latenz, Datenbankzeiten und I/O-Wartezeiten getrennt erfasst werden.

VPS- und Cloud-Knoten benötigen neben Rechenkapazität vor allem ausreichend RAM, Speicherbandbreite, Netzwerk und eine nachvollziehbare Ressourcenverteilung. CPU-Pinning, reservierter Speicher, NUMA-Zuordnung und Storage-QoS beeinflussen die Erfahrung der Gäste stärker als das Herstellerlogo. Datenbank-, Redis- und storage-nahe Systeme bewerten zusätzlich Working Set, Cache-Größe, Schreiblast und direkte Anbindung von NVMe-SSDs. Hier ist eine ausgewogene Plattformtopologie oft entscheidender als ein reiner Webserver-Durchsatzwert.

EPYC 9005 und Xeon 6 als Vergleichsbasis einordnen

Dieser Artikel vergleicht bewusst AMD EPYC 9005 und Intel Xeon 6 als klar abgegrenzte Plattformgenerationen. Die Gegenüberstellung dient der Beschaffung, Erweiterung oder Bewertung von Systemen auf Basis dieser beiden Produktfamilien. Aussagen zu anderen Generationen oder Produktzweigen lassen sich daraus nicht ableiten, weil sich Kernaufbau, Speicherplattform, I/O-Ausstattung und verfügbare Funktionen unterscheiden können.

Eine dokumentierte Prozessorfunktion ist außerdem von einem tatsächlich beschaffbaren Serversystem zu unterscheiden. Mainboard, Firmware, DIMM-Konfiguration, Kühlung, Netzteile und OEM-Freigaben bestimmen, welche Ausstattung praktisch nutzbar ist. Prüfe deshalb für jede konkrete SKU, welche Servermodelle erhältlich und für die geplante Bestückung validiert sind. Das gilt besonders für hohe RAM-Kapazitäten, zahlreiche NVMe-Laufwerke und spezielle Virtualisierungsfunktionen.

Ältere EPYC-700x-Generationen und frühere Xeon-Scalable-Modelle dürfen nicht unbemerkt mit EPYC 9005 oder Xeon 6 vermischt werden. Ebenso wenig sollten Daten anderer Produktzweige auf diese Familien übertragen werden. Kernaufbau, I/O-Ausstattung, Speicherplattform und verfügbare Funktionen können sich zwischen den Generationen unterscheiden. Ein Beschaffungsvergleich braucht daher stets die vollständige Modellbezeichnung, die Zahl der Sockel und das verwendete Server-Mainboard.

EPYC 9005 umfasst je nach Modell Prozessoren mit Zen 5– oder Zen-5c-Kernen. Diese Bezeichnungen beschreiben keine pauschale Rangfolge für Hosting. Relevant sind vielmehr die konkrete SKU, Kernzahl, Taktverhalten, thermische Vorgaben und die geplante Parallelität. Eine kernreiche Variante kann zu vielen gut begrenzten Mandanten passen, während ein anders positioniertes Modell für eine kleinere Zahl rechenintensiver Anwendungen geeigneter sein kann.

Intel trennt Xeon 6 in Varianten mit P-Cores und E-Cores. P-Cores sind auf hohe Leistung je Kern ausgerichtet und unterstützen unter anderem AVX-512 sowie AMX. Das kann relevant werden, wenn eingesetzte Software diese Vektor- oder Matrixfunktionen tatsächlich nutzt; ein gewöhnlicher PHP- oder Webserver-Stack erhält daraus nicht automatisch einen Vorteil. E-Cores zielen dagegen auf hohe Kerndichte und parallelen Durchsatz.

Für dicht gepackte, gut isolierte Shared- oder Cloud-Workloads können Xeon-6-E-Cores daher grundsätzlich in die engere Wahl kommen. Xeon-6-P-Cores oder passend konfigurierte EPYC-9005-Modelle sind bei Lasten mit höherem Bedarf an Einzelkernleistung ebenfalls naheliegende Kandidaten. Das ist eine Einordnung der Produktausrichtung, keine Leistungsgarantie. RAM-Ausbau, Firmware und Softwarekonfiguration können das Ergebnis wesentlich beeinflussen und einen Vergleich der Kernarten ohne identische Plattformkonfiguration verfälschen.

Kerne sind nur ein Faktor

CPU-Kerne entfalten ihren Nutzen nur, wenn Speicher und I/O mithalten. DDR5-Kanäle bestimmen zusammen mit Bestückung und DIMM-Typ die verfügbare Speicherbandbreite; die RAM-Kapazität begrenzt dagegen, wie viele VMs, Datenbankpuffer oder Caches ohne Auslagerung betrieben werden können. PCIe-Lanes verbinden NVMe-Laufwerke, Netzwerkkarten und gegebenenfalls Beschleuniger. Für Hosting muss diese Kette als Gesamtsystem geplant werden.

AMD dokumentiert für EPYC 9005 bis zu zwölf DDR5-Kanäle sowie, abhängig von Sockelzahl und Plattform, umfangreiche PCIe-Gen-5-Anbindung. Für Single-Socket-Systeme werden bis zu 128 PCIe-Gen-5-Lanes genannt. Intel Xeon 6 bietet je nach Serie ebenfalls bis zu zwölf DDR5-Kanäle; ausgewählte Single-Socket-P-Core-Konfigurationen erreichen bis zu 136 PCIe-Lanes. Diese Werte sind Modell- und Plattformdaten, keine Zusage zur Leistung einer Anwendung.

Ein VPS-Knoten mit mehreren NVMe-SSDs, zwei schnellen Netzwerkkarten und vielen VMs zeigt den praktischen Unterschied. Sind Laufwerke oder NICs über PCIe-Switches angebunden, teilen sie sich möglicherweise einen Uplink. Auch Lane-Aufteilung, Steckplätze, Bifurcation, CXL-Unterstützung und die tatsächlich freigeschaltete Firmware-Konfiguration bestimmt das Mainboard. Die dokumentierte CPU-Kapazität muss deshalb mit dem Blockdiagramm und der Validierung des konkreten Servers abgeglichen werden.

Bei Systemen mit mehreren NUMA-Knoten ist außerdem entscheidend, wo RAM, virtuelle CPUs und I/O-Geräte zugeordnet sind. Greift eine VM oder Datenbank häufig auf Speicher eines anderen Knotens zu, können zusätzliche Latenzen entstehen. Sinnvoll sind daher Messungen unter realistischer Belegung: CPU-Auslastung allein zeigt weder Speicherengpässe noch Warteschlangen am Storage oder Netzwerk.

Viele Lanes erleichtern die direkte Anbindung zahlreicher Geräte, garantieren aber weder niedrige Datenbanklatenz noch hohe Transaktionsraten. Controller, SSD-Firmware, RAID- oder Replikationsdesign, Queue-Tiefe und Netzwerkpfad bleiben maßgeblich. Die Wahl zwischen AMD EPYC Hosting und einem Intel-Xeon-Server sollte I/O- und Speicheranforderungen daher ebenso konkret erfassen wie Kernzahl und Takt.

Workloads mit der Plattform abgleichen

Die Auswahl beginnt nicht mit dem Hersteller, sondern mit der Verteilung der Last. Xeon 6 mit E-Cores kommt grundsätzlich für sehr viele voneinander unabhängige, sauber begrenzte Aufgaben in Betracht; Xeon 6 mit P-Cores für Anforderungen an Leistung pro Kern und bestimmte Vektor- oder Matrixoperationen. EPYC 9005 deckt ebenfalls unterschiedliche Kern- und Taktprofile ab. Daraus folgt keine Rangfolge: Entscheidend sind die konkrete SKU, die Servertopologie und die gemessene Anwendungslast.

Bei Shared Hosting ist hohe Kerndichte nur dann nützlich, wenn Limits für CPU-Zeit, Prozesse, Arbeitsspeicher und I/O Nachbaraccounts tatsächlich schützen. E-Core-Modelle können deshalb für stark parallelisierte Mandantenlandschaften passen. Ein EPYC-9005-Modell mit passendem Kernprofil kann ebenso geeignet sein. Für einzelne anspruchsvolle Shop- oder CMS-Instanzen sind dagegen Antwortzeiten pro Worker und die Datenbank wichtiger als die bloße Zahl verfügbarer Kerne.

VPS-Knoten und storage-nahe Dienste verlangen zusätzlich eine Prüfung der I/O-Topologie. EPYC 9005 dokumentiert je nach Plattform umfangreiche DDR5- und PCIe-5.0-Ressourcen; Xeon 6 bietet ebenfalls serien- und modellabhängige Speicherkanäle sowie PCIe-Lanes. Diese Angaben erleichtern die Vorauswahl, garantieren jedoch weder eine bestimmte NVMe-Latenz noch Datenbankdurchsatz. Mainboard, Bestückung, Firmware und Softwarepfad bleiben Teil der Entscheidung.

CPU-Benchmarks für Hosting richtig planen

Der Suchbegriff cpu benchmark hosting verleitet zu einer unzulässigen Verkürzung: Ein CPU-Ergebnis beschreibt kein Hosting-Angebot. SPEC behandelt Resultate als Ergebnisse vollständiger Systeme und verlangt die Offenlegung wesentlicher Konfigurationsdetails. Für einen Plattformvergleich müssen daher beide Kandidaten mit vergleichbarer Sockelzahl, Speicherbestückung, Storage, Netzwerk und Software getestet werden.

Für PHP-FPM reicht ein hoher Request-Durchsatz nicht aus. Eine Plattform kann bei kurzer synthetischer Last viele Antworten liefern und dennoch bei parallel ausgeführten Cronjobs oder langsamen Datenbankabfragen hohe p99-Werte erzeugen. Erfasse deshalb Warteschlangen, Fehlerraten und Antwortzeiten getrennt für dynamische und zwischengespeicherte Seiten. Versionskontrollierte Deployments helfen, die getestete Anwendung und Konfiguration eindeutig festzuhalten. Git-Workflows im Hosting

Bei Datenbanken müssen Datensatzgröße und Cache-Zustand dokumentiert sein, weil ein vollständig im RAM liegender Test andere Grenzen zeigt als ein I/O-lastiger Betrieb. Bei VPS-Dichte ist zusätzlich die Erfahrung im Gast maßgeblich. Welche Scheduling-Metrik aussagekräftig ist, hängt vom Hypervisor und Gastbetriebssystem ab; CPU-Ready-Zeit darf daher nicht als universell verfügbare Messgröße behandelt werden. Wiederhole Lastläufe und halte Messmethode sowie Abweichungen offen fest.

Konfiguration und Topologie prüfen

Vor einem Vergleich solltest du zuerst den Istzustand erfassen. Das verhindert, dass ein vermeintlicher CPU-Unterschied in Wahrheit aus einer anderen NUMA-Zuordnung, abweichendem Arbeitsspeicher oder einer geänderten Webserverkonfiguration stammt. Die folgenden Befehle lesen Informationen aus oder prüfen Konfigurationen; sie verändern weder CPU-Pinning noch Diensteinstellungen. Führe sie mit den im jeweiligen System erforderlichen Berechtigungen aus und archiviere die Ausgaben geschützt.

Mit lscpu dokumentierst du CPU-Modell, logische CPUs, Sockel, Kerne und erkannte NUMA-Knoten. numactl --hardware ergänzt, sofern das Werkzeug installiert ist, die verfügbaren CPUs und den Speicher je NUMA-Knoten. Beide Ausgaben beschreiben die erkannte Hardwaretopologie, nicht die tatsächliche Auslastung unter Hosting-Last.

lscpu
numactl --hardware
nginx -T
php-fpm -tt

Der Aufruf nginx -T gibt die wirksame NGINX-Konfiguration aus und kann deshalb interne Hostnamen, Dateipfade oder Zertifikatsreferenzen enthalten. Prüfe und bereinige solche Angaben, bevor du die Ausgabe weitergibst. php-fpm -tt steht exemplarisch für eine Konfigurationsprüfung; Binärname und Optionen unterscheiden sich je nach Distribution und PHP-Version. Prüfe vorab die lokal verfügbare Variante, statt eine produktive Konfiguration zu ändern.

Ein VPS-Praxisfall verdeutlicht den Zweck: Sind vCPUs einer VM auf Kerne eines NUMA-Knotens festgelegt, ihr reservierter RAM liegt aber überwiegend auf dem anderen Knoten, können Speicherzugriffe zusätzliche Latenz erhalten. Dokumentiere daher CPU-Pinning und RAM-Zuordnung gemeinsam. Erst danach lässt sich beurteilen, ob eine andere CPU-Plattform oder zunächst eine konsistentere Gasttopologie erforderlich ist.

Virtualisierung sicher und planbar betreiben

Bei VPS- und Cloud-Angeboten bestimmt nicht der Prozessorname allein die wahrgenommene Leistung. CPU-Pinning bindet vCPUs bei Bedarf an festgelegte physische Kerne und kann dadurch schwankende Laufzeiten reduzieren. Es ist jedoch eine Kapazitätsentscheidung: Exklusiv reservierte Kerne stehen nicht für eine flexible Verteilung an andere Kunden bereit. Für Tarife mit zugesicherter Rechenleistung sollte diese Reserve daher in der Auslastungsplanung enthalten sein.

Ebenso wichtig ist die NUMA-Affinität auf Mehrsockel- oder hochkernigen Systemen. Eine VM sollte möglichst Rechenkerne und Arbeitsspeicher aus demselben NUMA-Knoten nutzen. Greift sie regelmäßig auf Speicher eines anderen Knotens zu, können zusätzliche Zugriffswege die Latenz erhöhen. Plane deshalb große VMs zunächst nach lokaler RAM-Kapazität und Kernzuordnung, statt nur die Summe aller Kerne und des gesamten Arbeitsspeichers zu betrachten.

Reservierter RAM verhindert, dass zugesagte Speicherkapazität nur aus einer optimistischen Überbuchung entsteht. Ergänzend begrenzt Storage-QoS IOPS, Durchsatz oder Warteschlangen je VM, damit ein Backup, ein Datenbankimport oder ein fehlkonfigurierter Gast nicht den gemeinsamen NVMe-Pool blockiert. Lege Überbuchungsgrenzen getrennt für CPU, RAM und Storage fest: Eine tragfähige CPU-Quote macht einen Knoten nicht belastbar, wenn sein Storage bereits unter Spitzenlast hohe Wartezeiten erzeugt.

Für vertrauliche virtuelle Maschinen bieten beide Plattformen Funktionen, die über die gewöhnliche Virtualisierung hinausgehen. AMD dokumentiert für EPYC 9005 SEV, SEV-ES und SEV-SNP; SEV-SNP ergänzt Mechanismen zum Schutz bestimmter Seitentabellen- und Speicherzuordnungsangriffe. Intel beschreibt TDX als Technik, bei der Gastbetriebssystem und VM-Anwendungen gegenüber Cloud-Host, Hypervisor und anderen VMs auf der Plattform isoliert werden.

Solche Funktionen machen weder einen AMD-EPYC- noch einen Intel-Xeon-Server automatisch sicherer. Für Intel TDX sind unterstützte Prozessoren, eine passende DIMM-Bestückung und die konkrete OEM- oder ODM-Plattform zu prüfen; die dokumentierten DIMM-Vorgaben können je nach Plattformimplementierung abweichen. Darüber hinaus setzt die Nutzbarkeit ein abgestimmtes Zusammenspiel aus Firmware, Hypervisor, Kernel, Gastbetriebssystem und Betriebsprozessen voraus. Prüfe außerdem Schlüssellebenszyklus, Attestierung, Wiederherstellung und Monitoring. Ohne diese Abläufe kann eine aktivierte Hardwarefunktion die Schutzanforderung eines Kunden nicht vollständig abdecken.

Fehlerquellen bei Vergleich und Betrieb

Ein belastbarer Vergleich beginnt mit gleicher Systemgröße. Ein Server mit zwei Sockeln darf nicht einem Ein-Sockel-System gegenüberstehen, wenn die Beschaffungsfrage eine Plattformklasse betrifft. Halte pro Test CPU-Modell, Sockelzahl, aktive Kerne, RAM-Menge und DIMM-Bestückung fest. Nur so wird sichtbar, ob ein Ergebnis auf der Architektur, zusätzlicher Hardware oder einer abweichenden Konfiguration beruht.

Auch ungleicher Speicher und ungleiches I/O verfälschen Schlussfolgerungen. Unterschiedliche DDR5-Kanalbelegung, NVMe-Generationen, RAID-Layout, Netzwerkkarten oder BIOS-Energieprofile verändern Durchsatz und Latenzen erheblich. AMD weist für EPYC 9005 darauf hin, dass die konkrete I/O-Konfiguration von Plattform und Mainboard abhängt; dokumentierte Schnittstellenkapazität ist daher keine Zusage für die Anwendung.

Viele PCIe-Lanes erleichtern zwar die direkte Anbindung mehrerer NVMe-Laufwerke und schneller Netzwerkkarten. Sie garantieren aber keine niedrige Datenbanklatenz: Warteschlangen im Storage, Controller-Firmware, Replikation, Datenbankparameter und das Arbeitsset im RAM bleiben maßgeblich. Für storage-nahe Architekturen ergänzt der Beitrag Webhosting für IoT-Plattformen die Perspektive auf Netzwerklatenz, Segmentierung und Speicherpfade.

Isolierte Boost-Takte sind ebenfalls kein Hosting-Benchmark. AMD definiert den maximalen Boost als Frequenz, die ein einzelner Kern unter normalen Serverbedingungen erreichen kann; unter paralleler Dauerlast gelten andere thermische und energetische Rahmenbedingungen. Miss daher Antwortzeit-Perzentile und Durchsatz unter repräsentativer Gleichzeitigkeit, statt aus einer einzelnen Taktangabe auf die Leistung eines ganzen Knotens zu schließen.

TDP ist schließlich keine Messung des tatsächlichen Serververbrauchs. Für Kostenannahmen brauchst du Messwerte des vollständigen Systems mit gewähltem RAM, Storage, Netzwerklast und Energieprofil. Die Vergleichbarkeit öffentlicher Ergebnisse verlangt außerdem vollständige Systemangaben; SPEC behandelt Resultate ausdrücklich als Ergebnisse kompletter Systeme, nicht einzelner Prozessoren.

Beschaffung nach messbaren Anforderungen entscheiden

Dokumentiere zuerst das Lastprofil: Anzahl und Größe der Mandanten, typische und maximale Gleichzeitigkeit, PHP- oder Anwendungsanteil, Datenbankabfragen, Cache-Trefferquote, RAM je Instanz sowie I/O- und Netzwerkspitzen. Daraus entsteht keine abstrakte Rangliste, sondern ein Anforderungskatalog. Erst dieser zeigt, ob hohe Kerndichte, kurze Antwortzeiten einzelner Worker oder eine besonders umfangreiche Storage-Anbindung den Ausschlag geben.

Lege anschließend fest, ob du eine vorhandene Plattform erweiterst, gebrauchte oder lagernde Systeme bewertest oder eine vollständig neue Serverkonfiguration beschaffst. Bei EPYC 9005 und Xeon 6 müssen Verfügbarkeit, OEM-Freigaben, Firmwarepflege und Ersatzteilplanung für das konkrete Servermodell geprüft werden. Die Bezeichnung der CPU-Familie allein belegt weder Lieferbarkeit noch die Validierung der gewünschten RAM-, Storage- und Netzwerkausstattung.

Vergleiche danach konkrete SKUs samt Sockeltopologie und Serverplattform. Für AMD EPYC 9005 sind Kernvariante, Modell sowie der geplante DDR5- und PCIe-Ausbau zu prüfen. Die Familie umfasst Zen-5- und Zen-5c-Modelle, deren Eigenschaften nicht pauschal gleichgesetzt werden dürfen. Bei Intel Xeon 6 ist insbesondere zwischen P-Core- und E-Core-Varianten zu unterscheiden, weil sie unterschiedliche Ziele bei Leistung pro Kern und Kerndichte verfolgen.

Prüfe den Ausbau als vollständige Stückliste: validierte DIMM-Konfiguration, lokaler RAM pro NUMA-Knoten, Zahl und Anbindung der NVMe-Laufwerke, NICs, PCIe-Switches sowie Kühlung und Netzteile. Ein EPYC-9005-Hosting-Knoten ist naheliegend, wenn eine konkret verfügbare Konfiguration die geforderte Kombination aus Kernen, Speicherkanälen und I/O bereitstellt. Das ist eine Eignungsprüfung der gewählten SKU und Serverplattform, kein allgemeiner Leistungsvorsprung gegenüber Intel Xeon.

Ein Intel-Xeon-6-Server mit E-Cores kann bei vielen gut begrenzten, unabhängigen Workloads eine plausible Option sein. P-Core-Modelle kommen eher in Betracht, wenn einzelne Anwendungen hohe Leistung pro Kern benötigen oder passende Vektor- und Matrixfunktionen relevant sind. Intel nennt AVX-512 und AMX für Xeon-6-P-Cores; ob diese Funktionen helfen, hängt jedoch von der eingesetzten Software und ihrer konkreten Implementierung ab.

Führe vor der Bestellung einen reproduzierbaren Test mit den eigenen Images, Konfigurationen und realitätsnahen Datenmengen durch. Erfasse neben Requests pro Sekunde auch Fehlerquote, Antwortzeit-Perzentile, Datenbankwartezeiten, Storage-Latenzen und Verhalten bei parallelen Backups oder Ausfällen. Vollständige Angaben zu Hard- und Software sind nötig, damit spätere Entscheidungen nachvollziehbar bleiben.

Ein Pilotbetrieb ist sinnvoll, wenn geplante Mandantendichte, neue Hypervisor-Funktionen, ein ungewohntes NVMe-Design oder Energiekosten die Kalkulation stark beeinflussen. Betreibe dabei eine begrenzte, repräsentative Kunden- oder Testgruppe mit klaren Ressourcenlimits. Erst nach beobachteten Spitzenlasten, Kapazitätsreserven und Betriebsabläufen lassen sich Hochrechnung, Einkauf und Rollout fachlich begründen.