Ga naar de inhoud 
CPU-architectuur Hosting heeft een directe invloed op hoe snel webservers aanvragen verwerken: Een hoge kloksnelheid zorgt voor single-thread prestaties, terwijl een grote cache de toegangstijd tot gegevens verkort en de TTFB in het nanosecondenbereik duwt. Ik leg uit hoe klokfrequentie, aantal cores en L1-L3 cache op elkaar inwerken en welke echte effecten dit heeft op PHP, MySQL en WordPress.
Centrale punten
- Tact drijft single-thread snelheid op en houdt seriële delen kort.
- Cache vermindert de RAM-latentie en verlaagt de TTFB aanzienlijk.
- L3/Kern telt meer voor multitenancy dan een puur core-nummer.
- NUMA beïnvloedt geheugenpaden en coherentieverkeer.
- Turbo en all-core boost bepalen de effectieve kloksnelheid.
Klokfrequentie versus parallellisme in hosting
Ik beoordeel Klokfrequentie en het aantal cores zijn altijd hetzelfde, omdat seriële codepaden de kloksnelheid zwaarder laten wegen. Veel webstacks hebben een duidelijke single-threaded component: request parsing, routing, delen van PHP uitvoering en mutex gebieden in databases reageren bijzonder goed op een hoge basisklok en all-core turbo. Hoewel hoge core-nummers snelheid laten zien met zeer parallelle API's, worden seriële gedeelten langzamer als de klok laag is. Daarom geef ik vaak de voorkeur aan CPU's met een hogere kloksnelheid en veel L3 per core voor dynamische sites. Als je dieper wilt graven, kun je achtergrondinformatie vinden op de Kloksnelheid in hosting, die het single-thread voordeel verklaart en typische werkbelastingen categoriseert; juist deze focus voorkomt verkeerde inschattingen en versterkt de echte Prestaties.
Cache-hiërarchie: L1, L2, L3 en hun invloed
De CPU-cache werkt als een Afkorting naar de waarheid over latentie: Elk niveau bespaart tijd en minimaliseert RAM-toegang. L1 blijft klein maar supersnel, L2 verhoogt de hitsnelheid per core, L3 bundelt hotsets voor veel threads en voorkomt constant herladen vanuit het hoofdgeheugen. In webomgevingen betekenen hits in L1-L3 minder context-switches, minder wachttijd voor I/O en een merkbaar snellere tijd tot de eerste byte. Ik plan hosting nodes daarom zo dat de L3 cache hotsets bevat die bestaan uit bytecode, frequente query resultaten en metadata, terwijl L1/L2 instructies en smalle datastructuren levert. Als je de basisbeginselen wilt lezen, ga dan naar L1-L3 in hosting oriëntatie; daar wordt duidelijk waarom een sterke L3 vaak belangrijker is dan extra RAM werkt.
| Cache-niveau | Typische grootte | Latency | Gedeeld | Effect in hosting |
|---|---|---|---|---|
| L1 | ~64 KB per kern | Zeer laag (ns) | Geen | Houdt strakke instructie-/gegevensvolumes vast, versnelt hot loops |
| L2 | 256 KB–1 MB per kern | Laag (ns) | Geen | Vermindert missers van L1, ontlast L3 en RAM |
| L3 | Tot 512 MB+ totaal | Laag (ns) | Ja | Vangt willekeurige toegangen op; bevat bytecode, indexdelen, hotsets |
| RAM | GB gebied | Hoger (µs) | Systeemwijd | Basislijn; latentie neemt toe en doorvoer neemt af bij missers |
Echt effect op TTFB, PHP en databases
Ik meet vooruitgang met TTFB en percentielen omdat ze een directe invloed hebben op de gebruikerservaring en SEO. Als L3 hotsets buffert van PHP bytecode, Composer autoload maps en WordPress opties, worden cold misses geëlimineerd en wordt de responstijd merkbaar verkort. Hetzelfde geldt voor frequente DB-query's, die in L3 blijven als result sets of indexdelen en beschikbaar zijn voor nieuwe hits zonder een RAM-sprong. Deze effecten tellen op bij hoog parallellisme omdat elke vermeden RAM toegang de wachtrijen verkort. Op sites met een hoge frequentie houden warm-ups en vooraf laden de cache warm, verminderen uitschieters en stabiliseren het 95e percentiel op Belasting.
SMT/Hyper-Threading, Core-Isolation en buren met ruis
Simultaneous Multithreading (SMT) verhoogt de doorvoer, maar splitst L1/L2-bronnen en bandbreedte van de uitvoeringseenheden. In webstacks met veel kortstondige verzoeken levert SMT vaak meer antwoorden per seconde op, maar het kan de latency van individuele threads verhogen als twee „luidruchtige“ buren op dezelfde core zitten. Ik isoleer daarom latency-kritische pools (bijvoorbeeld PHP-FPM front workers of DB threads) naar hun eigen fysieke cores en laat batch jobs/queue workers hun SMT broers en zussen gebruiken. Dit houdt de single-thread klok effectief zonder cache trash te creëren tussen siblings. Op multitenant hosts gebruik ik CPU affiniteit en cgroups om te regelen dat vCPU's contigu aan cores van een L3 slice worden toegewezen. Dit vermindert cache-interferentie, stabiliseert de 95e en 99e percentiel en dempt „noisy neighbour“ effecten aanzienlijk.
Takvoorspelling, µOP-cache en prefetcher in de webstack
Hoog IPC is afhankelijk van goede voorspelling: moderne cores versnellen hot loops via branch predictor, µOP cache en data/instructie prefetcher. Geïnterpreteerde code (PHP) en „indirecte“ routing genereren soms sprongen die moeilijk te voorspellen zijn - verkeerde voorspellingen kosten tientallen cycli. Ik houd hete paden slank (minder voorwaardelijke takken, korte functieketens) en profiteer dus meer van de µOP-cache. Orde in autoload maps, preloading en het vermijden van te grote framework path traversals zorgen ervoor dat de instructie werkruimte in L1/L2 blijft. Aan de gegevenskant helpen dichte structuren: smalle arrays, korte strings, weinig pointer indirecties. Hoe lineairder de toegangen, hoe beter de prefetchers werken; de pijplijn blijft vol en L3 wordt vaker gebruikt.
NUMA en threadplaatsing: hoe latentie te vermijden
Bij multi-socket systemen let ik op NUMA, zodat threads geen toegang hebben tot extern geheugen op verschillende nodes. Ik bind PHP FPM pools, webserver-workers en database-instanties aan hetzelfde NUMA-knooppunt om L3-voordelen en korte geheugenpaden te garanderen. Dit vermindert coherency verkeer, houdt missers lager en verbetert de voorspelbaarheid onder piekbelasting. In VPS-omgevingen vraag ik om vCPU-clustering per node zodat hotsets niet tussen L3 slices switchen. Als je deze clustering serieus neemt, bespaar je een verrassend aantal microseconden per verzoek en maak je de Jitter.
L3 per kern begrijpen en correct evalueren
Ik beoordeel L3/Kern als een belangrijk criterium, vooral op multitenant hosts. Een hoge totale capaciteit heeft alleen een sterk effect als deze voldoende ruimte biedt voor hotsets per actieve core en niet verdeeld is over te veel threads. Bij hoog gebruik concurreren processen om gedeelde L3 slices; de curve kantelt dan en missers nemen toe. Om deze reden presteert een model met minder cores maar meer L3 per core en een hogere kloksnelheid vaak beter op dynamische sites. Ik leg de relatie tussen single-thread snelheid en parallellisme in meer detail uit onder Single-thread vs. multi-core, want dat is precies waar de echte Efficiëntie.
Turbo, all-core boost en effectieve kloksnelheid onder belasting
Ik meet de effectieve Tact onder echte belasting, niet alleen de waarden uit de datasheet. Turbomechanismen stimuleren individuele cores, maar bij veel parallelle verzoeken is een boost voor alle cores en de vraag hoe lang de CPU dit kan volhouden het belangrijkste. Thermische limieten, stroomverbruik en koeling bepalen of de kloksnelheid na minuten inzakt of stabiel blijft. In hostingscenario's met een constante belasting leveren modellen met een hoge all-core klok en een royale L3 de meest constante tijden. Dit betekent dat de latentie voorspelbaar blijft, terwijl pieken minder uitschieters naar het 99e percentiel duwen en de Schalen werkt betrouwbaarder.
Crypto, AVX-breedten en downclockeffecten
Cryptografie en vectorinstructies versnellen TLS, compressie en mediapaden, maar kunnen klokstoringen veroorzaken. AVX2/AVX-512 zetten prestatiebudgetten onder druk, waarbij sommige CPU's de kloksnelheid aanzienlijk verlagen. Daarom heb ik CPU-profielen gescheiden: TLS terminators of beeldverwerking draaien op speciale cores (of zelfs aparte nodes), terwijl request parsers en PHP workers op „snelle“ P cores met een hoge kloksnelheid blijven. AES-NI en moderne ChaCha20 implementaties leveren sterke prestaties zonder latentiepieken te genereren als de belasting verstandig wordt verdeeld. In hybride architecturen (E/P cores) zet ik latentiekritische threads expliciet vast op P cores en laat ik achtergrondwerk gebruik maken van E cores - dit houdt percentielen strak en turbo's stabiel.
Meetbare kerncijfers: IPC, missers, 95e percentiel
Ik observeer IPC (Instructies per cyclus), missers en percentielen omdat ze knelpunten zichtbaar maken. Een hoge IPC geeft aan dat de pijplijnvoeding correct is en dat de cache de cores voedt. Stijgende miss rates wijzen op te kleine caches, ongunstige plaatsing of ongeschikte thread-distributie. In de latency-percentielen kijk ik of de staart breder wordt, wat duidt op cache thrash of NUMA-crusades. Ik gebruik deze kengetallen om upgrades gericht te sturen: meer L3 per core, betere all-core klokken of schone affiniteiten brengen de Curves weer samen.
Methodologie: Hoe ik belasting test en percentielen vergelijk
Ik meet nooit koud: voor elke run warm ik de OPcache, autoload maps en DB hotsets op zodat de echte effecten zichtbaar worden. Daarna varieer ik systematisch het parallellisme (zelfs RPS-trappen, burst-profielen) en houd ik de netwerkkant constant. Tools met percentiel evaluatie en hergebruik van verbindingen laten zien hoe goed cache hits aanslaan en of keep-alive strategieën de L3 ontlasten. Parallel daaraan registreer ik hardwaretellers en scheduler-metriek (IPC, L1/L2/L3 misses, contextwissels, run queue lengte) om correlaties tussen miss pieken en latency uitschieters te herkennen. Pas als de 95e/99e percentielen stabiel zijn, vergelijk ik de doorvoer. Op deze manier zijn klokdalingen, turboduur en cache thrash duidelijker te herkennen dan met eenvoudige piekbenchmarks.
Oefening: warming-up, voorbelasting en warme sets
Ik houd Caches Opwarmen voordat het verkeer binnenrolt, zodat koude missers niet de eerste bezoekers treffen. Het voorladen van PHP-OPcache, het pingen van frequente WordPress-routes en het voorverwarmen van DB-query's zijn eenvoudige hefbomen. Bij implementaties start ik specifiek opwarmsequenties die bytecode, autoload maps en primaire indexpadsegmenten naar L3 tillen. Vervolgens controleer ik de TTFB-mediaan en het 95e percentiel om het succes van de opwarming te controleren. Als er uitschieters zijn, pas ik de affiniteiten aan, verminder ik het aantal processen per socket of verwijder ik overbodige processen. Plugins.
PHP 8: OPcache, JIT en FPM procesmodellen
OPcache is de belangrijkste versneller voor PHP-stacks omdat het bytecode stabiel houdt in het geheugen en zo instructiecaches voedt. Ik verhoog het geheugen van OPcache, schakel frequente timestamp-controle in productie uit en gebruik preloading voor gecentraliseerde classes. De PHP 8 JIT helpt selectief met numerieke routines, maar vergroot de instructievoetafdruk; met typische WordPress workloads verslechtert het soms de cache localiteit. Ik activeer het daarom alleen na een meting. In FPM stel ik pm = static of goed afgestelde dynamische instellingen in zodat processen niet constant gerecycled worden en hun hotsets in L2/L3 blijven. Te veel kinderen degraderen L3/core, te weinig creëren wachtrijen - ik zoek naar de sweet spot waar 95e percentielen smal blijven en de run queue niet groeit.
MySQL/InnoDB: Bufferpool vs. CPU-cache en threadpools
De InnoDB bufferpool beslist over RAM hits, maar L3 bepaalt hoe snel hot index levels en kleine result sets herhaaldelijk worden afgeleverd. Ik kijk of de bovenste B-tree niveaus in de L3 hot sets terecht komen (access locality), en houd rijen smal: weinig, selectieve indexen, overeenkomende datatypes en dekkende indexen voor primaire paden. Dit vermindert willekeurige geheugenverplaatsingen. Indien nodig vertraag ik hoog parallelisme met een thread pool om context switches en L3 thrash te dempen. NUMA-localiteit blijft verplicht: DB-processen, IRQ-wachtrijen van de NVMe SSD's en de betreffende vCPU-groep bevinden zich op dezelfde node. Dit vermindert coherentieverkeer en scans, sorteren en joins raken „koude“ regio's minder vaak.
Hardwarestack: CPU-generatie, RAM, SSD's en I/O
Ik combineer CPU, RAM en I/O zodat de CPU nooit hoeft te wachten op gegevens. Nieuwere generaties met DDR5 en PCIe 5.0 bieden meer bandbreedte, waardoor NVMe SSD's verzoeken sneller kunnen afleveren en de cache minder vaak mist. Energiezuinige modellen besparen elektriciteit in euro's, zorgen ervoor dat turbo's langer meegaan en verminderen de warmte in het rack. Belangrijk: Voldoende RAM blijft verplicht, maar bovenaan bepaalt de cache of dynamische pagina's knallen of twitchen. Als je een budget plant, investeer dan eerst geld in CPU-modellen met een sterke all-core klok en veel L3 per core en let daarna op snelle NVMe.
Virtualisatie, containers en IRQ-besturing
Onder KVM en in containers telt de topologie: ik zorg ervoor dat vCPU's worden geleverd als aaneengesloten cores van een NUMA-node en niet over sockets springen. In Kubernetes gebruik ik CPU-verzoeken/limieten met een statische CPU-manager zodat pods echte cores krijgen en hun hotsets niet migreren. Ik verdeel netwerkbelasting via RSS/multiqueue naar die cores die ook de webwerkers dragen en bind IRQ's aan dezelfde NUMA nodes - zodat RX/TX paden lokaal blijven. Ik verplaats ook opslag interrupts van de NVMe SSD's naar dit domein. Resultaat: minder context-switches, minder externe hits, smallere percentielen ondanks hoog parallellisme. Deze „thuishygiëne“ kost geen hardware, maar wijst cachebronnen toe waar ze latency echt verminderen.
Kort samengevat: Prioriteiten en aankoopcontrole
Ik geef hoge prioriteit aan Tact, veel L3 per core en schone NUMA-plaatsing vóór al het andere, omdat deze hendels de grootste sprongen in dynamische werkbelastingen opleveren. Daarna controleer ik de all-core boost en houd ik de koeling zo dat de effectieve klok niet instort. Voor multitenancy kies ik configuraties met consistente L3-toegang per vCPU en duidelijke affiniteiten zodat hotsets niet afdwalen. In benchmarks hecht ik meer waarde aan de TTFB-mediaan en het 95e percentiel dan aan pure doorvoerpieken, omdat gebruikers uitschieters sneller opmerken dan topwaarden. Als u deze volgorde aanhoudt, zult u merkbaar snellere sites krijgen, resources besparen en dure upgrades vermijden die anders een negatieve invloed zouden hebben op de werkelijke prestaties. knelpunt voorbij.
