Warum CPU Cache (L1–L3) im Hosting wichtiger als RAM ist

CPU Cache Hosting entscheidet in vielen realen Workloads über Ladezeit und TTFB, weil L1–L3 Daten in Nanosekunden direkt am Kern bereitstellen und so den langsamen RAM-Zugriff umgehen. Ich zeige klar, wann Cache-Größe und -Hierarchie die Rechenzeit dominieren und weshalb mehr RAM ohne starken Cache kaum Wirkung entfaltet.

Zentrale Punkte

• L1–L3 puffert Hot-Daten näher am Kern und senkt Latenz deutlich.
• Cache-Hierarchie schlägt RAM bei dynamischen Anfragen und hoher Parallelität.
• Cache pro Kern zählt bei VPS/DEDI mehr als reine RAM-Menge.
• Workloads wie WordPress, DB-Queries und PHP profitieren direkt.
• Tarifwahl mit CPU-Fokus liefert spürbar schnellere Antworten.

Warum CPU-Cache L1–L3 Hosting spürbar beschleunigt

Ein Cache sitzt direkt am Prozessor und liefert Anweisungen sowie Daten ohne Umweg über das Mainboard. L1 ist klein, aber extrem schnell; L2 erweitert den Puffer; L3 hält viel Abrufmaterial für alle Kerne bereit. So vermeidet der Prozessor Wartezeiten, die beim Zugriff auf RAM entstehen. Diese Wartezeiten summieren sich bei Webservern, da jeder Request mehrere Datenbank- und Filesystem‑Zugriffe auslöst. Ich sehe in Logs immer wieder, wie kurze Cache‑Treffer lange RAM‑Zugriffe ersetzen und so TTFB und CPU‑Auslastung senken.

So arbeiten L1, L2 und L3 zusammen

Der L1‑Cache liefert Instruktionen und Daten in wenigen Taktzyklen, was Latenz auf minimale Werte drückt. Trifft L1 nicht, bedient L2 die Anfrage mit etwas mehr Zeitbedarf. Verfehlt L2, springt L3 ein, der im Verhältnis groß ist und die Trefferquote hochhält. Erst wenn L3 verfehlt, landet die CPU beim RAM, was den Zyklus verlangsamt. Ich plane Hosting daher so, dass pro Kern ausreichend L3 verfügbar ist, weil genau dort viele parallele Webprozesse auf gemeinsame Datensätze zugreifen.

Cache vs. RAM: Zahlen im Überblick

Ich fasse die typischen Größen und relativen Geschwindigkeiten zusammen, damit die Einordnung leichter fällt. Die Werte schwanken je nach CPU‑Generation, doch die Relationen bleiben ähnlich. L1 ist sehr klein und extrem fix, L2 liegt in der Mitte, L3 ist groß und teilt sich oft zwischen Kernen. RAM bringt Kapazität, aber höhere Zugriffszeit und schwächelt bei zufälligen Zugriffen. Genau diese zufälligen Zugriffe dominieren in Webserver-Stacks aus Webserver, PHP und Datenbank.

Speicherstufe	Typische Größe	Latenz (relativ)	Faktor vs. RAM	Geteilt?
L1 (Instruktionen/Daten)	32–64 KB pro Kern	extrem gering	bis ~170× schneller	nein
L2	256 KB–1 MB pro Kern	sehr gering	deutlich schneller	nein
L3	bis 40 MB+, geteilt	niedrig	bis ~15× schneller	oft ja
RAM (DDR)	GB-Bereich	hoch	Baseline	Systemweit

Cache-Architektur im Detail: inklusiv, exklusiv, Chiplets

Nicht jeder L3 ist gleich: Einige Architekturen fahren einen inklusiven L3 (er hält Kopien der L1/L2‑Zeilen), andere setzen auf exklusiv/mostly-exclusive (L3 enthält zusätzliche Zeilen, die nicht in L1/L2 liegen). Inklusiv steigert die Kohärenz‑Einfachheit, kostet aber effektiven Platz. Exklusiv nutzt die Kapazität besser, verlangt jedoch schlaues Victim‑Management. In chiplet‑basierten Designs ist L3 oft pro Die gebündelt; Anfragen, die auf einem anderen Die landen, zahlen eine Extra‑Latenz. Für Hosting heißt das: Ich versuche, Workloads und ihre Hotsets pro Die zu bündeln, damit der überwiegende Teil der Zugriffe im lokalen L3 bleibt. Das senkt Varianz und stabilisiert das 95./99. Perzentil.

Reale Workloads: WordPress, Datenbanken, APIs

Dynamische Seiten starten viele kleine Zugriffe: PHP holt Templates, MySQL liefert Rows, der Webserver liest Dateien. Treffen diese Muster im Cache, sinkt die TTFB direkt. WordPress zeigt das sehr klar, besonders bei CPU‑gebundenen Themes und vielen Plugins. Wer tiefer einsteigt, findet typische Engpässe in CPU-bound WordPress beschrieben. Ich plane dafür Cores mit viel L3 pro Kern, weil das Query‑Hotset und Bytecode‑Fragmente häufiger im Puffer bleiben.

Praxiswerte: Das Hotset einer mittelgroßen WordPress‑Site liegt oft im einstelligen Megabyte‑Bereich (Opcache-Bytecode, Autoloader‑Maps, häufige DB‑Indizes). E‑Commerce‑Shops bringen zusätzlich Preis‑ und Lager‑Indizes sowie Session‑Daten ins Spiel. Passt dieses Bündel in L3, reduziert sich das Auf und Ab der Antwortzeit deutlich – selbst ohne Änderungen an Applikation oder RAM‑Größe.

Cores, Threads und Cache pro Kern

Viele Cores helfen nur, wenn pro Kern genug Cache bereitsteht, sonst konkurrieren Threads stärker. Hyper‑Threading verdoppelt nicht die Rechenleistung, teilt sich aber die Cachestruktur. Mit mehr L3 pro Kern bleibt die Auslastung stabil und die Varianz der Antwortzeiten klein. Besonders Multitenant‑VPS profitieren, weil sich Hotsets mehrerer Sites im gemeinsamen L3 halten. Ich achte deshalb auf das Verhältnis Cores zu L3‑Kapazität, nicht bloß auf den reinen Core‑Zähler.

Ein häufiger Irrtum: “Mehr Threads = mehr Durchsatz.” In der Praxis steigen Konflikt‑Misses und Kontextwechsel. Ich limitiere Worker exakt so, dass IPC (Instructions per Cycle) hoch bleibt und die Miss‑Raten nicht weglaufen. Das liefert in Lasttests oft bessere Perzentile als ein “maximale Parallelität”-Ansatz.

NUMA, Speicherzugriff und Latenzfallen

Moderne Server nutzen oft mehrere NUMA-Knoten, was Wege im Speicher verlängern kann. Wer Prozesse quer über Knoten verteilt, vergrößert die Latenz und reduziert Cache‑Treffer. Ich ziehe es vor, Services so zu binden, dass Hotsets lokal bleiben. Ein kurzer Überblick zur NUMA-Architektur zeigt, wie wichtig Nähe zwischen Kern, Cache und RAM-Bank ist. Mit guter Platzierung sichern Anfragen mehr Cache‑Treffer und weniger teure Ausflüge in entfernten Speicher.

Wichtig: Cross‑NUMA‑Traffic ist nicht nur ein RAM‑Thema. Auch L3‑Kohärenz über Knoten erhöht Latenz. Deshalb teste ich unter Last, auf welchem NUMA‑Knoten die aktive Datenbank und PHP‑FPM‑Pools liegen, und halte Web‑ und DB‑Prozesse möglichst in derselben Topologie. Das verhindert, dass Sessions, Query‑Pläne und Bytecode ständig “über die Straße” geschoben werden.

I/O wartet auf die CPU: Warum RAM selten der Engpass ist

RAM-Kapazität hilft beim Filesystem‑Cache, doch die meiste Wartezeit entsteht im Codepfad der Anwendung. Diese Pfade profitieren von schnellen Instruktions‑ und Datencaches, nicht von mehr Gigabytes. Bei zufälligen Zugriffen verpufft RAM‑Bandbreite schnell, während ein großer L3 die Sprünge abfedert. Ich messe in Profilern, dass Cache‑Miss‑Raten eng mit TTFB und 95. Perzentil korrelieren. Deshalb gewichte ich CPU‑Cache höher als reine RAM‑Größe, bis die Miss‑Rate sinkt.

Auch SSDs “wirken” schneller, wenn die CPU weniger wartet. Weniger Kontextwechsel und kürzere Codepfade bedeuten, dass I/O‑Completion schneller verarbeitet wird. Caches sind hier der Katalysator: Sie halten die Hot‑Instruktionspfade warm und minimieren Stalls, während der Scheduler weniger Threads hin‑ und herschieben muss.

Cache‑Miss‑Typen verstehen und gezielt senken

Ich unterscheide in der Praxis vier Ursachen:

• Compulsory Misses (kalt): Erste Zugriffe auf neue Daten; durch Warm‑Up‑Strategien reduzierbar (Preload der häufigsten Routen, Warmer für Opcache).
• Capacity Misses: Hotset passt nicht komplett in Lx; durch kleinere Codepfade, weniger Plugins und optimierte Indizes senke ich die Größe.
• Conflict Misses: Zu viele Zeilen mappen auf dieselben Sets; bessere Datenlokalität und reduzierte Streuung helfen, ebenso “glattere” Datenstrukturen.
• Coherence Misses: Geteilte Daten werden oft geschrieben; ich minimiere globale Mutables und nutze lokale Caches (APCu), um Write‑Traffic zu dämpfen.

Auf Anwendungsebene bedeutet das: Ich reduziere Zufallszugriffe (z. B. weniger scatter‑gather in PHP), fasse Queries zusammen, halte Objekt‑Caches konsistent und achte darauf, dass Hot‑Code nicht ständig neu kompiliert oder neu geladen wird.

Praktische Kaufkriterien für Hosting-Tarife

Ich prüfe bei VPS und dedizierten Servern zuerst die CPU-Generation, dann Cache‑Größe pro Kern. Ein Tarif mit weniger RAM, aber starkem L3 pro Kern schlägt oft ein Modell mit viel RAM und schwachem Cache. Wichtig sind auch Takt unter Last, Turbo‑Verhalten und wie der Anbieter Cores zuteilt. Für Shops mit vielen gleichzeitigen Anfragen zahlt sich L3‑Kapazität überproportional aus. Wer ohnehin Caches in App, DB und CDN nutzt, profitiert zusätzlich von einer Cache‑starken CPU, weil Hotsets häufiger treffen.

Ich frage explizit nach: Wie viele vCPUs pro physischen Kern teilt der Anbieter? Werden vCPUs über NUMA‑Grenzen gemischt? Gibt es Garantien, dass vCPUs innerhalb desselben Dies liegen? Solche Details entscheiden, ob L3 als Beschleuniger wirkt oder durch Noisy Neighbors verwässert wird.

Tuning: Software nutzt den Cache besser

Ich halte PHP‑Opcache, JIT‑Settings und DB‑Buffer so, dass Hotpfade in L3 passen und Re‑Compiles selten sind. Zu hartes Thread‑Pinnen hemmt Scheduler‑Optimierungen; warum das oft wenig bringt, zeigt CPU-Pinning. Stattdessen begrenze ich Worker so, dass sie nicht den Cache verdrängen. Ich sorge für kurze Codepfade, weniger Abzweigungen und warme Bytecode‑Caches. So sinken Miss‑Raten, und der Prozessor verbringt mehr Zeit mit Nutzarbeit statt mit Warten.

In PHP‑Stacks liefern OPcache‑Speicher und interned strings merklich bessere Lokalität. Zusätzlich setze ich auf einen lokalen APCu für Read‑heavy Daten und einen persistenten Objekt‑Cache (z. B. Redis) mit überschaubarer Schlüsselanzahl, damit Hot‑Keys in L3 verbleiben. In der Datenbank reduziere ich sekundäre Indexe auf das Nötige und optimiere die Sortierreihenfolge, damit Sequenzen statt Sprungmuster entstehen.

Messgrößen: Was ich monitore

Ich beobachte ständig Miss‑Rates (L1/L2/L3), IPC (Instructions per Cycle) und Takt unter Last. Zusätzlich prüfe ich TTFB, 95./99. Perzentil und Error‑Logs bei Lastwechseln. Diese Kennzahlen zeigen, ob der Codepfad in den Cache passt oder wegrutscht. Ich korreliere Miss‑Spitzen mit Deployments, Traffic‑Peaks und neuen Plugins. So finde ich schnell die Stellen, an denen mehr Cache‑Treffer den größten Nutzen bringen.

Für Ad‑hoc‑Analysen schaue ich live auf “perf stat”‑Metriken wie cycles, instructions, branches, branch‑misses und LLC‑Misses. Dauerhaft nutze ich Aufzeichnungen, die Frequenz unter Last (turbostat) und Kontextwechsel pro Sekunde zeigen. Wenn IPC unter Druck fällt und LLC‑Misses gleichzeitig hochgehen, ist der Engpass fast immer Cache‑Kapazität oder Datenlokalität – nicht der RAM‑Durchsatz.

Benchmarking und Testaufbau: realistische Antworten messen

Ich teste mit repräsentativen Routen statt nur statischen Dateien. Ein Mix aus Startseite, Produktdetail, Suche und Checkout deckt unterschiedliche Codepfade ab. Mit abgestuften Laststufen (kalt, warm, heiß) erkenne ich, wie schnell der Cache sich füllt und wo er kippt. Wichtig ist die Steady‑State‑Phase, in der Frequenz, IPC und Miss‑Rate stabil laufen. Erst hier vergleiche ich Tarife und CPU‑Generationen fair.

Messbare Signale:

• TTFB‑Median fällt nach Warm‑Up deutlich und bleibt niedrig → Caches wirken.
• 95./99. Perzentil driftet bei Peak‑Last nur leicht → genügend L3 pro Kern.
• IPC steigt mit weniger Workern → Konflikte und Misses nehmen ab.
• LLC‑Misses korrelieren mit neuen Plugins/Features → Hotset vergrößert.

Ich dokumentiere pro Test die aktive CPU‑Frequenz, Worker‑Zahl, Route‑Mix und ggf. NUMA‑Platzierung. So lassen sich Optimierungen eindeutig zuordnen und reproduzieren.

Virtualisierung und Multitenancy: Cache teilen ohne ihn zu verlieren

In VPS‑Umgebungen teilen sich Mandanten denselben physischen L3. Werden vCPUs eines Gastes breit über die Maschine verteilt, verliert man Lokalität. Gute Anbieter bündeln vCPUs eines Gastes auf derselben CCX/CCD/Tile. Ich sehe das in stabileren Perzentilen und geringerer Varianz. Zusätzlich begrenze ich Worker, damit mein eigener Stack den L3 nicht überflutet und mit Nachbarn in Konflikt geht.

Container auf demselben Host konkurrieren ähnlich. Ein schlanker Basiskontainer mit vorgewärmtem Opcache und möglichst wenig dynamischem Autoloading hält den L3 sauber. Ich vermeide aggressive Sidecars auf dem gleichen Knoten, die hohe Instruktions‑Flächen produzieren (z. B. “alles loggen, überall”). Das gehört auf einen separaten Knoten oder außerhalb der Hot‑Pfad‑CPU.

Prefetcher, TLB und Seitengrößen: versteckte Hebel

Moderne CPUs besitzen Prefetcher, die lineare Muster vorziehen. Je sequentieller Code und Daten angeordnet sind, desto mehr bringt das. Ich ziehe deshalb strukturierte Arrays und kompaktere Strukturen Hash‑lastigen und stark verzweigten Layouts vor. Zudem achte ich auf die TLB (Translation Lookaside Buffer): Viele Page‑Walks sind teuer und reißen L1/L2 mit. Große Seitengrößen (Huge Pages) können helfen, Bytecode‑ und DB‑Hotsets mit weniger TLB‑Einträgen abzudecken. In InnoDB‑ und JIT‑Konfigurationen prüfe ich daher, ob größere Seiten messbar Vorteile bringen – immer mit A/B‑Messung, denn nicht jeder Stack profitiert gleich.

Praxis‑Checkliste: schnelles Cache‑Hosting in 10 Schritten

• CPU‑Generation und L3 pro Kern prüfen, nicht nur Core‑Zahl und RAM.
• vCPU‑Zuteilung erfragen: Bündelung pro Die/NUMA statt Streuung.
• Worker auf IPC‑Sweetspot begrenzen; Varianz der Perzentile minimieren.
• PHP‑Opcache großzügig, aber zielgerichtet dimensionieren; Re‑Compiles vermeiden.
• Persistente Objekt‑Caches nutzen, Schlüsselraum schlank halten.
• DB‑Indizes auf Hot‑Queries zuschneiden; Zufallszugriffe reduzieren.
• NUMA‑Lokalität sicherstellen: Web, PHP, DB im selben Knoten, wo möglich.
• Prefetcher‑freundliche Datenpfade: sequentieller, weniger Sprünge.
• Deployments mit Warm‑Up versehen; kalte Misses vor Traffic‑Peaks abfangen.
• Monitoring: IPC, L1/L2/L3‑Miss‑Rate, Takt, 95./99. Perzentil kontinuierlich korrelieren.

Kurz zusammengefasst

Im Hosting beschleunigt ein starker CPU‑Cache L1–L3 jeden dynamischen Request, während zusätzlicher RAM vor allem Kapazität liefert. Ich priorisiere daher Cache‑Größe pro Kern, saubere Prozessplatzierung und passende Worker‑Zahlen. In Tools sehe ich: Weniger Misses erzeugen messbar bessere Antwortzeiten und stabile Perzentile. Wer Tarife auswählt, sollte auf Cache‑Angaben und CPU‑Generation achten, nicht allein auf GB‑Angaben. So holt man aus derselben Software mehr Leistung heraus – ganz ohne teure Hardware‑Upgrades.