Waarom CPU-cache (L1-L3) belangrijker is dan RAM in hosting

CPU-cachehosting is in veel echte workloads bepalend voor de laadtijd en TTFB, omdat L1-L3-gegevens in nanoseconden rechtstreeks aan de kern worden geleverd en zo de trage RAM-toegang omzeilen. Ik laat duidelijk zien wanneer cachegrootte en -hiërarchie de rekentijd domineren en waarom meer RAM zonder krachtige cache nauwelijks effect heeft.

Centrale punten

• L1–L3 buffer hot data dichter bij de kern en vermindert de latentie aanzienlijk.
• Cachehiërarchie verslaat RAM bij dynamische verzoeken en hoge parallelliteit.
• Cache per kern is bij VPS/DEDI belangrijker dan alleen de hoeveelheid RAM.
• Werklasten zoals WordPress, DB-query's en PHP profiteren hier direct van.
• Tariefkeuze met CPU-focus levert merkbaar snellere antwoorden.

Waarom CPU-cache L1–L3 hosting merkbaar versnelt

A Cache zit direct op de processor en levert instructies en gegevens zonder omweg via het moederbord. L1 is klein, maar extreem snel; L2 breidt de buffer uit; L3 houdt veel opvraagbaar materiaal voor alle kernen klaar. Zo vermijdt de processor wachttijden bij het benaderen van RAM ontstaan. Deze wachttijden stapelen zich op bij webservers, omdat elk verzoek meerdere database- en bestandssysteemtoegangen activeert. Ik zie in logbestanden steeds weer hoe korte cache-hits lange RAM-toegangen vervangen en zo TTFB en CPU-gebruik verlagen.

Zo werken L1, L2 en L3 samen

De L1-cache levert instructies en gegevens in slechts enkele klokcycli, wat Latency tot minimale waarden drukt. Als L1 niet raakt, verwerkt L2 de aanvraag met iets meer tijd. Als L2 mist, springt L3 bij, die relatief groot is en het trefpercentage hoog houdt. Pas als L3 mist, komt de CPU bij het RAM terecht, wat de cyclus vertraagt. Ik plan hosting daarom zo dat er per kern voldoende L3 beschikbaar is, omdat juist daar veel parallelle webprocessen toegang hebben tot gemeenschappelijke gegevenssets.

Cache versus RAM: cijfers in één oogopslag

Ik vat de typische groottes en relatieve snelheden samen, zodat de Classificatie gemakkelijker. De waarden variëren afhankelijk van de CPU-generatie, maar de verhoudingen blijven vergelijkbaar. L1 is erg klein en extreem snel, L2 ligt in het midden, L3 is groot en wordt vaak gedeeld tussen cores. RAM biedt capaciteit, maar hogere toegangstijd en vertoont zwakke punten bij willekeurige toegangen. Juist deze willekeurige toegangen domineren in webserverstacks bestaande uit webservers, PHP en databases.

geheugenniveau	Typische grootte	Latentie (relatief)	Factor vs. RAM	Gedeeld?
L1 (instructies/gegevens)	32–64 KB per kern	extreem laag	tot ~170× sneller	geen
L2	256 KB–1 MB per kern	zeer gering	Aanzienlijk sneller	geen
L3	tot 40 MB+, gedeeld	laag	tot ~15× sneller	vaak ja
RAM (DDR)	GB-gebied	hoog	Basislijn	Systeemwijd

Cache-architectuur in detail: inclusief, exclusief, chiplets

Niet elke L3 is hetzelfde: sommige architecturen rijden een inclusief L3 (houdt kopieën van de L1/L2-regels), anderen vertrouwen op exclusief/voornamelijk exclusief (L3 bevat extra regels die niet in L1/L2 staan). Inclusief verhoogt de coherentie en eenvoud, maar kost effectieve ruimte. Exclusief maakt beter gebruik van de capaciteit, maar vereist slim slachtofferbeheer. In op chiplets gebaseerde ontwerpen is L3 vaak per Die gebundeld; verzoeken die op een ander terechtkomen, betalen een extra latentie. Voor hosting betekent dit: ik probeer, Workloads en hun hotsets per dag te bundelen, zodat het overgrote deel van de toegangen in de lokale L3 blijft. Dat vermindert de variatie en stabiliseert het 95e/99e percentiel.

Reële workloads: WordPress, databases, API's

Dynamische pagina's starten veel kleine Toegang tot: PHP haalt sjablonen op, MySQL levert rijen, de webserver leest bestanden. Als deze patronen in de cache terechtkomen, daalt de TTFB direct. WordPress laat dit heel duidelijk zien, vooral bij CPU-gebonden thema's en veel plug-ins. Wie dieper graaft, vindt typische knelpunten in CPU-gebonden WordPress beschreven. Ik plan daarvoor cores met veel L3 per kern, omdat de query-hotset en bytecodefragmenten vaker in de buffer blijven.

Praktijkwaarden: De hotset van een middelgrote WordPress-site ligt vaak in het bereik van enkele megabytes (Opcache-bytecode, autoloader-maps, frequente DB-indexen). E-commercewinkels brengen bovendien prijs- en voorraadindexen en sessiegegevens in het spel. Als dit pakket in L3 past, worden de schommelingen in de responstijd aanzienlijk verminderd, zelfs zonder wijzigingen in de applicatie of RAM-grootte.

Kernen, threads en cache per kern

Veel cores helpen alleen als er per kern voldoende Cache beschikbaar is, anders concurreren threads sterker met elkaar. Hyper-threading verdubbelt de rekenkracht niet, maar deelt de cache-structuur. Met meer L3 per kern blijft de belasting stabiel en de variatie in responstijden klein. Vooral multitenant-VPS'en profiteren hiervan, omdat hotsets van meerdere sites in de gemeenschappelijke L3 blijven. Ik let daarom op de verhouding tussen cores en L3-capaciteit, niet alleen op de pure kernmeter.

Een veel voorkomende misvatting: “Meer threads = meer doorvoer.” In de praktijk nemen conflicten en contextwisselingen toe. Ik beperk workers precies zo dat IPC (Instructions per Cycle) hoog blijft en de miss-percentages niet weglopen. Dit levert in belastingstests vaak betere percentielen op dan een “maximale parallelliteit”-benadering.

NUMA, geheugentoegang en latentievalkuilen

Moderne servers maken vaak gebruik van meerdere NUMA-knooppunt, wat de paden in het geheugen kan verlengen. Wie processen over knooppunten verspreidt, vergroot de latentie en vermindert cache-hits. Ik geef er de voorkeur aan om services zo te koppelen dat hotsets lokaal blijven. Een kort overzicht van de NUMA-architectuur toont aan hoe belangrijk de nabijheid tussen de kern, cache en RAM-bank is. Met een goede plaatsing zorgen verzoeken voor meer cache-hit en minder dure uitstapjes naar verre oorden.

Belangrijk: Cross-NUMA-verkeer is niet alleen een RAM-kwestie. Ook L3-coherentie via knooppunten verhoogt de latentie. Daarom test ik onder belasting op welk NUMA-knooppunt de actieve database en PHP-FPM-pools zich bevinden en houd ik web- en DB-processen zoveel mogelijk in dezelfde topologie. Dit voorkomt dat sessies, queryplannen en bytecode voortdurend “over de weg” worden verplaatst.

I/O wacht op de CPU: waarom RAM zelden de bottleneck is

RAM-capaciteit helpt bij het bestandssysteemcache, maar het grootste deel wachttijd ontstaat in het codepad van de applicatie. Deze paden profiteren van snelle instructie- en gegevenscaches, niet van meer gigabytes. Bij willekeurige toegangen verdwijnt RAM-bandbreedte snel, terwijl een grote L3 de sprongen opvangt. Ik meet in profilers dat cache-miss-percentages nauw correleren met TTFB en 95. percentiel. Daarom weeg ik CPU-cache zwaarder dan pure RAM-grootte, totdat het percentage mislukkingen daalt.

Ook SSD's “werken” sneller als de CPU minder hoeft te wachten. Minder contextwisselingen en kortere codepaden betekenen dat I/O-voltooiing sneller wordt verwerkt. Caches zijn hier de katalysator: ze houden de hot-instructiepaden warm en minimaliseren vertragingen, terwijl de planner minder threads heen en weer hoeft te schuiven.

Cache-miss-types begrijpen en gericht verminderen

In de praktijk onderscheid ik vier oorzaken:

• Verplichte missers (koud): eerste toegang tot nieuwe gegevens; kan worden verminderd door opwarmstrategieën (voorladen van de meest voorkomende routes, warmer voor Opcache).
• Capaciteitsverlies: Hotset past niet volledig in Lx; door kleinere codepaden, minder plug-ins en geoptimaliseerde indexen verklein ik de omvang.
• Conflict mist: Te veel regels verwijzen naar dezelfde sets; betere gegevenslokaliteit en verminderde verspreiding helpen, evenals “gladdere” gegevensstructuren.
• Coherentie mist: Gedeelde gegevens worden vaak geschreven; ik minimaliseer globale mutables en gebruik lokale caches (APCu) om schrijfverkeer te dempen.

Op applicatieniveau betekent dit: ik verminder willekeurige toegangen (bijv. minder scatter-gather in PHP), voeg queries samen, houd objectcaches consistent en zorg ervoor dat hot-code niet voortdurend opnieuw wordt gecompileerd of opnieuw wordt geladen.

Praktische aankoopcriteria voor hostingpakketten

Bij VPS en dedicated servers controleer ik eerst de CPU-generatie, vervolgens cachegrootte per kern. Een tarief met minder RAM, maar een sterke L3 per kern verslaat vaak een model met veel RAM en een zwakke cache. Ook belangrijk zijn de kloksnelheid onder belasting, het turbogedrag en de manier waarop de aanbieder cores toewijst. Voor winkels met veel gelijktijdige verzoeken loont L3-capaciteit buitenproportioneel. Wie toch al caches in app, DB en CDN gebruikt, profiteert bovendien van een Cache-sterk CPU, omdat hotsets vaker voorkomen.

Ik vraag expliciet: hoeveel vCPU's per fysieke kern Deelt de aanbieder? Worden vCPU's gemengd over NUMA-grenzen heen? Zijn er garanties dat vCPU's binnen dezelfde dies liggen? Dergelijke details bepalen of L3 als versneller werkt of door noisy neighbors verwaterd wil.

Tuning: software maakt beter gebruik van de cache

Ik houd PHP‑Opcache, JIT‑instellingen en DB‑Buffer zo dat hotpads in L3 passen en recompilaties zijn zeldzaam. Te hard thread-pinnen remt scheduler-optimalisaties; waarom dit vaak weinig oplevert, blijkt uit CPU pinning. In plaats daarvan beperk ik workers zodat ze de cache niet verdringen. Ik zorg voor korte codepaden, minder vertakkingen en warme bytecode-caches. Zo dalen de miss-percentages en besteedt de processor meer tijd aan nuttig werk in plaats van wachten.

Leveren in PHP-stacks OPcache-geheugen en geïnterneerde strings aanzienlijk betere locatie. Daarnaast zet ik in op een lokale APCu voor read-heavy gegevens en een persistent objectcache (bijv. Redis) met een overzichtelijk aantal sleutels, zodat hotkeys in L3 blijven. In de database reduceer ik secundaire indexen tot het noodzakelijke minimum en optimaliseer ik de sorteervolgorde, zodat er sequenties ontstaan in plaats van sprongpatronen.

Meetgrootheden: wat ik monitor

Ik observeer voortdurend Miss-Rates (L1/L2/L3), IPC (Instructions per Cycle) en kloksnelheid onder belasting. Daarnaast controleer ik TTFB, 95e/99e percentiel en foutlogboeken bij belastingswisselingen. Deze kengetallen laten zien of het codepad in de cache past of wegglijdt. Ik correleer miss-pieken met implementaties, verkeerspieken en nieuwe plug-ins. Zo vind ik snel de plaatsen waar meer cache-hit het grootste nut opleveren.

Voor ad-hocanalyses kijk ik live op “perfect stat”‑statistieken zoals cycles, instructions, branches, branch‑misses en LLC‑Misses. Ik gebruik continu registraties, de frequentie onder belasting (turbostat) en contextwisselingen per seconde weergeven. Als IPC onder druk komt te staan en LLC-misses tegelijkertijd toenemen, is de bottleneck bijna altijd de cachecapaciteit of datalocaliteit – niet de RAM-doorvoer.

Benchmarking en testopzet: realistische antwoorden meten

Ik test met representatieve routes in plaats van alleen statische bestanden. Een mix van startpagina, productdetails, zoekfunctie en checkout dekt verschillende codepaden af. Met verschillende belastingsniveaus (koud, warm, heet) kan ik zien hoe snel de cache volloopt en waar hij omvalt. Belangrijk is de Steady-state-fase, waarbij de frequentie, IPC en miss-rate stabiel blijven. Pas dan kan ik tarieven en CPU-generaties eerlijk vergelijken.

Meetbare signalen:

• TTFB-mediaan daalt aanzienlijk na opwarmen en blijft laag → caches werken.
• 95/99 percentiel verschuift slechts licht bij piekbelasting → voldoende L3 per kern.
• IPC stijgt met minder werknemers → conflicten en misverstanden nemen af.
• LLC-misses correleren met nieuwe plug-ins/functies → Hotset vergroot.

Per test documenteer ik de actieve CPU-frequentie, het aantal workers, de routemix en, indien van toepassing, de NUMA-plaatsing. Zo kunnen optimalisaties duidelijk worden toegewezen en gereproduceerd.

Virtualisatie en multitenancy: cache delen zonder deze te verliezen

In VPS-omgevingen delen klanten dezelfde fysieke L3. Als vCPU's van een gast breed over de machine worden verdeeld, verliest man Locatie. Goede aanbieders bundelen vCPU's van een gast op dezelfde CCX/CCD/Tile. Ik zie dat terug in stabielere percentielen en minder variatie. Daarnaast beperk ik workers, zodat mijn eigen stack de L3 niet overspoelt en in conflict komt met buren.

Containers op dezelfde host concurreren op vergelijkbare wijze. Een slanke basiscontainer met voorverwarmde Opcache en zo min mogelijk dynamisch autoloading houdt de L3 schoon. Ik vermijd agressieve sidecars op hetzelfde knooppunt, die hoge instructieoppervlakken produceren (bijv. “alles loggen, overal”). Dat hoort op een apart knooppunt of buiten de hot-path-CPU.

Prefetcher, TLB en paginagroottes: verborgen hefbomen

Moderne CPU's hebben Prefetcher, die lineaire patronen verkiezen. Hoe sequentiëler code en gegevens zijn geordend, hoe meer dat oplevert. Ik geef daarom de voorkeur aan gestructureerde arrays en compactere structuren boven hash-lastige en sterk vertakte lay-outs. Daarnaast let ik op de TLB (Translation Lookaside Buffer): Veel paginawalk-bewerkingen zijn duur en hebben invloed op L1/L2. Grote paginagroottes (Huge Pages) kunnen helpen om bytecode- en DB-hotsets met minder TLB-vermeldingen te dekken. In InnoDB- en JIT-configuraties controleer ik daarom of grotere pagina's meetbare voordelen opleveren – altijd met A/B-metingen, omdat niet elke stack evenveel profiteert.

Praktische checklist: snelle cachehosting in 10 stappen

• CPU-generatie en L3 per kern Controleer niet alleen het aantal cores en het RAM-geheugen.
• vCPU-toewijzing opvragen: bundeling per Die/NUMA in plaats van verspreiding.
• Beperk het aantal werknemers tot het IPC-sweetspot; minimaliseer de variantie van de percentielen.
• PHP-Opcache royaal, maar doelgericht dimensioneren; hercompilaties vermijden.
• Gebruik persistente objectcaches, houd de sleutelruimte compact.
• DB-indexen afstemmen op veelvoorkomende zoekopdrachten; willekeurige toegangen verminderen.
• Zorg voor NUMA-lokaliteit: web, PHP, DB in hetzelfde knooppunt, waar mogelijk.
• Prefetcher-vriendelijke gegevenspaden: sequentieel, minder sprongen.
• Deployments voorzien van warm-up; koude missers vóór verkeerspieken opvangen.
• Monitoring: IPC, L1/L2/L3-miss-rate, kloksnelheid, 95e/99e percentiel continu correleren.

Kort samengevat

In hosting versnelt een sterke CPU-cache L1–L3 elke dynamische aanvraag, terwijl extra RAM vooral capaciteit levert. Ik geef daarom prioriteit aan cachegrootte per kern, nette procesplaatsing en passende aantallen workers. In Tools zie ik: minder missers zorgen voor meetbaar betere responstijden en stabiele percentielen. Wie tarieven kiest, moet letten op cachegegevens en CPU-generatie, niet alleen op GB-gegevens. Zo haal je meer uit dezelfde software. Prestaties zonder dure hardware-upgrades.