AMD EPYC eller Intel Xeon: Sådan vælger du den rigtige platform til webhosting

Hostingprofiler før sammenligningen af CPU’er

Webhosting udgør ikke en ensartet CPU-arbejdsbelastning. En platform med tusindvis af små konti følger andre regler end en node til virtuelle maskiner eller en databaseserver. Inden man sammenligner AMD EPYC og Intel Xeon, bør man derfor fastlægge forespørgselsprofilen, antallet af samtidigt aktive klienter, RAM-behovet, storage-I/O og de acceptable svartider. Først denne kombination gør en CPU’s tekniske data meningsfulde i forbindelse med indkøb.

delt hosting behandler mange indbyrdes uafhængige PHP-, CMS- og e-mail-opgaver med ofte korte belastningsspidser. En høj kerne tæthed kan hjælpe, men effektive begrænsninger for CPU-tid, processer, arbejdshukommelse og I/O er lige så vigtige. Uden sådanne begrænsninger kan en enkelt konto optage knappe ressourcer og forringe responstiderne for andre kunder. Planlagt klientadskillelse er her ofte vigtigere end en spidsværdi i en syntetisk multicore-test.

Når det gælder administrerede CMS-systemer og webshops, er kravene mere varierede. Dynamiske PHP-anmodninger, objektcache, databaseforespørgsler, cron-jobs og administratoradgang forekommer til tider samtidigt. For nogle få krævende applikationer kan Ydelse pr. kerne være vigtigere end det maksimale antal kerner; hvis der derimod konstant er mange uafhængige PHP-FPM-workere, får parallelitet større betydning. Det afgørende er dog stadig, om webserveren, PHP-processerne og databasen er dimensioneret korrekt.

En WooCommerce-butik illustrerer denne opdeling: En webserver med cache kan levere statiske produktbilleder meget effektivt. Indkøbskurv, kasse og lagerbeholdning genererer imidlertid personaliseret PHP-udførelse og databaseadgang. Flere CPU-kerner fjerner ikke ventetiden, hvis forespørgsler mangler indekser, bufferpoolen er for lille, eller NVMe-latensen stiger under belastning. Derfor bør forespørgselslatens, databasetider og I/O-ventetider registreres separat.

VPS- og cloud-knudepunkter kræver ud over regnekapacitet først og fremmest tilstrækkelig RAM, lagerbåndbredde, netværk og en gennemsigtig ressourcefordeling. CPU-pinning, reserveret hukommelse, NUMA-tildeling og Storage-QoS har større indflydelse på gæsternes oplevelse end producentens logo. Database-, Redis- og lagringsrelaterede systemer vurderer desuden working set, cache-størrelse, skrivebelastning og direkte tilslutning af NVMe-SSD'er. Her er en afbalanceret Platformstopologi ofte mere afgørende end en ren webserver-gennemstrømningsværdi.

Placere EPYC 9005 og Xeon 6 som sammenligningsgrundlag

Denne artikel sammenligner bevidst AMD EPYC 9005 og Intel Xeon 6 som klart afgrænsede platformgenerationer. Sammenligningen tjener til anskaffelse, udvidelse eller vurdering af systemer baseret på disse to produktfamilier. Der kan ikke udledes konklusioner om andre generationer eller produktlinjer heraf, da kernekonstruktion, hukommelsesplatform, I/O-udstyr og tilgængelige funktioner kan variere.

En dokumenteret processorfunktion adskiller sig desuden fra en faktisk et tilgængeligt serversystem at skelne mellem. Bundkort, firmware, DIMM-konfiguration, køling, strømforsyninger og OEM-godkendelser afgør, hvilket udstyr der reelt kan bruges. Kontroller derfor for hver konkret SKU, hvilke servermodeller der er tilgængelige, og som er valideret til den planlagte konfiguration. Dette gælder især for store RAM-kapaciteter, mange NVMe-drev og specielle virtualiseringsfunktioner.

Ældre EPYC-700x-generationer og tidligere Xeon Scalable-modeller må ikke forveksles med EPYC 9005 eller Xeon 6. Ligeledes bør data fra andre produktlinjer ikke overføres til disse produktfamilier. Kernestruktur, I/O-udstyr, hukommelsesplatform og tilgængelige funktioner kan variere mellem generationerne. En sammenligning af indkøb kræver derfor altid den fulde modelbetegnelse, antallet af sokler og det anvendte serverbundkort.

EPYC 9005 omfatter, afhængigt af modellen, processorer med Zen 5– eller Zen-5c-kerner. Disse betegnelser angiver ikke en generel rangorden for hosting. Det, der er relevant, er snarere den konkrete SKU, antallet af kerner, taktshastigheden, de termiske specifikationer og den planlagte parallelitet. En variant med mange kerner kan passe til mange velafgrænsede klienter, mens en model med en anden positionering kan være mere velegnet til et mindre antal beregningsintensive applikationer.

Intel opdeler Xeon 6 i varianter med P-kerner og E-kerner. P-kerner er designet til høj ydeevne pr. kerne og understøtter blandt andet AVX-512 og AMX. Dette kan være relevant, hvis den anvendte software rent faktisk udnytter disse vektor- eller matrixfunktioner; en almindelig PHP- eller webserver-stack får ikke automatisk nogen fordel heraf. E-kerner er derimod rettet mod høj kerntæthed og parallel gennemstrømning.

Til tætpakkede, velisolerede shared- eller cloud-workloads kan Xeon 6 E-kerner derfor generelt komme i betragtning. Xeon 6 P-kerner eller passende konfigurerede EPYC 9005-modeller er ligeledes oplagte kandidater til arbejdsbelastninger med større behov for enkeltkernelyd. Dette er en inddeling af produktretningen, ikke en ydelsesgaranti. RAM-udvidelse, firmware og softwarekonfiguration kan have væsentlig indflydelse på resultatet og forvride en sammenligning af kernetyperne, hvis platformskonfigurationen ikke er identisk.

Kerner er blot én faktor

CPU-kerner udnytter kun deres fulde potentiale, hvis hukommelsen og I/O-kapaciteten kan følge med. DDR5-kanaler bestemmer sammen med antallet af moduler og DIMM-typen den tilgængelige hukommelsesbåndbredde; RAM-kapaciteten begrænser derimod, hvor mange virtuelle maskiner, databasebuffere eller cacher der kan køre uden paging. PCIe-baner forbinder NVMe-drev, netværkskort og eventuelt acceleratorer. Til hosting skal denne kæde planlægges som et samlet system.

AMD angiver for EPYC 9005 op til tolv DDR5-kanaler samt, afhængigt af antallet af sokler og platformen, omfattende PCIe Gen 5-tilslutning. For systemer med én sokkel angives op til 128 PCIe Gen 5-baner. Intel Xeon 6 tilbyder ligeledes op til tolv DDR5-kanaler afhængigt af serien; udvalgte single-socket P-Core-konfigurationer når op til 136 PCIe-baner. Disse værdier er model- og platformdata og udgør ikke en garanti for en applikations ydeevne.

En VPS-node med flere NVMe-SSD’er, to hurtige netværkskort og mange virtuelle maskiner viser den praktiske forskel. Hvis drev eller netværkskort er tilsluttet via PCIe-switche, deler de muligvis en uplink. Også lane-fordeling, stikpladser, bifurcation, CXL-understøttelse og den faktisk aktiverede firmwarekonfiguration bestemmes af bundkortet. Den dokumenterede CPU-kapacitet skal derfor afstemmes med blokdiagrammet og valideringen af den konkrete server.

I systemer med flere NUMA-noder er det desuden afgørende, hvor RAM, virtuelle CPU’er og I/O-enheder er allokeret. Hvis en VM eller database ofte tilgår hukommelse på en anden node, kan der opstå yderligere forsinkelser. Det er derfor fornuftigt at foretage målinger under realistiske belastningsforhold: CPU-udnyttelsen alene afslører hverken hukommelsesflaskehalse eller køer på lagringsenheden eller i netværket.

Mange baner gør det lettere at tilslutte en lang række enheder direkte, men garanterer hverken lav databaselatens eller høje transaktionshastigheder. Controlleren, SSD-firmwaren, RAID- eller replikeringsdesignet, kødybden og netværksstien er stadig afgørende. Valget mellem AMD EPYC-hosting og en Intel Xeon-server bør derfor registrere I/O- og hukommelseskrav lige så præcist som antallet af kerner og klokfrekvensen.

Synkronisere arbejdsbelastninger med platformen

Valget starter ikke med producenten, men med fordelingen af arbejdsbyrden. Xeon 6 med E-kerner er generelt velegnet til mange indbyrdes uafhængige, klart afgrænsede opgaver; Xeon 6 med P-kerner til krav til Ydelse pr. kerne og bestemte vektor- eller matrixoperationer. EPYC 9005 dækker ligeledes forskellige kerne- og taktsfrekvensprofiler. Dette betyder ikke, at der er tale om en rangorden: Det afgørende er den konkrete SKU, servertopologien og den målte applikationsbelastning.

Ved shared hosting er en høj kerne-tæthed kun nyttig, hvis begrænsningerne for CPU-tid, processer, RAM og I/O rent faktisk beskytter nabokonti. E-Core-modeller kan derfor være velegnede til stærkt paralleliserede klientmiljøer. En EPYC-9005-model med et passende kerneprofil kan ligeledes være velegnet. For enkelte krævende webshop- eller CMS-instanser er responstider pr. worker og databasen derimod vigtigere end det rene antal tilgængelige kerner.

VPS-knudepunkter og tjenester tæt på lagringsmediet kræver desuden en kontrol af I/O-topologi. EPYC 9005 angiver, afhængigt af platformen, omfattende DDR5- og PCIe 5.0-ressourcer; Xeon 6 tilbyder ligeledes hukommelseskanaler og PCIe-baner, der varierer alt efter serie og model. Disse oplysninger letter forudvælgelsen, men garanterer hverken en bestemt NVMe-latens eller databasegennemstrømning. Bundkort, konfiguration, firmware og softwarevalg er stadig en del af beslutningen.

Sådan planlægger du CPU-benchmarks korrekt til hosting

Søgeordet CPU-benchmark-hosting fører til en uberettiget forenkling: Et CPU-resultat beskriver ikke et hostingtilbud. SPEC betragter resultaterne som resultater fra komplette systemer og kræver, at væsentlige konfigurationsdetaljer offentliggøres. For at kunne sammenligne platforme skal begge kandidater derfor testes med sammenligneligt antal sokler, hukommelse, lagerplads, netværk og software.

For PHP-FPM er en høj anmodningsgennemstrømning ikke tilstrækkelig. En platform kan levere mange svar ved kortvarig syntetisk belastning og alligevel generere høje p99-værdier ved parallelt kørende cron-jobs eller langsomme databaseforespørgsler. Registrer derfor køer, fejlprocenter og svartider separat for dynamiske og cachelagrede sider. Versionsstyrede implementeringer hjælper med entydigt at fastlægge den testede applikation og konfiguration. Git-workflows ved hosting

Når det gælder databaser, skal datapoststørrelsen og cache-tilstanden dokumenteres, da en test, der udelukkende foregår i RAM, viser andre begrænsninger end en I/O-intensiv drift. Når det gælder VPS-tæthed, er erfaringerne i gæstsystemet desuden afgørende. Hvilken planlægningsmetrik der er relevant, afhænger af hypervisoren og gæstoperativsystemet; CPU-Ready-tid må derfor ikke betragtes som en universelt anvendelig måleparameter. Gentag belastningstestene, og dokumenter målemetoden samt afvigelser på en åben måde.

Kontroller konfiguration og topologi

Inden du foretager en sammenligning, bør du først kortlægge den aktuelle tilstand. Dette forhindrer, at en formodet forskel i CPU-ydeevne i virkeligheden skyldes en anden NUMA-tildeling, afvigende RAM eller en ændret webserverkonfiguration. De følgende kommandoer udlæser oplysninger eller kontrollerer konfigurationer; de ændrer hverken CPU-pinning eller tjenesteindstillinger. Udfør dem med de nødvendige rettigheder i det pågældende system, og arkiver udskrifterne sikkert.

Med lscpu Du dokumenterer CPU-model, logiske CPU'er, sokkel, kerner og registrerede NUMA-knudepunkter. numactl --hardware Hvis værktøjet er installeret, suppleres oplysningerne med de tilgængelige CPU’er og hukommelsen pr. NUMA-node. Begge udskrifter beskriver den registrerede hardwaretopologi, ikke den faktiske udnyttelse under hostingbelastning.

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

Opfordringen nginx -T viser den gældende NGINX-konfiguration og kan derfor indeholde interne værtsnavne, filstier eller certifikatreferencer. Kontroller og rens sådanne oplysninger, inden du videregiver udskriften. php-fpm -tt Dette er et eksempel på en konfigurationskontrol; det binære filnavn og indstillingerne varierer afhængigt af distributionen og PHP-versionen. Kontroller først den lokalt tilgængelige version, i stedet for at ændre en produktiv konfiguration.

Et praktisk eksempel på VPS illustrerer formålet: Hvis en VM’s vCPU’er er bundet til kerner på en NUMA-node, men den reserverede RAM hovedsageligt befinder sig på den anden node, kan hukommelsesadgange medføre yderligere latenstid. Dokumenter derfor CPU-pinning og RAM-allokering i fællesskab. Først derefter kan man vurdere, om der er behov for en anden CPU-platform eller i første omgang en mere konsistent gæstetopologi.

Sikker og planlagt drift af virtualisering

Når det gælder VPS- og cloud-tilbud, er det ikke kun processornavnet, der afgør den oplevede ydeevne. CPU-pinning knytter vCPU’er til bestemte fysiske kerner efter behov og kan dermed reducere svingninger i kørselstiderne. Det er dog et spørgsmål om kapacitet: Eksklusivt reserverede kerner er ikke tilgængelige for en fleksibel fordeling til andre kunder. For abonnementer med garanteret regnekraft bør denne reserve derfor indgå i udnyttelsesplanlægningen.

Lige så vigtig er NUMA-affinitet på systemer med flere sockets eller mange processorkerner. En VM bør så vidt muligt bruge processorkerner og RAM fra den samme NUMA-node. Hvis den regelmæssigt tilgår hukommelse fra en anden node, kan de ekstra adgangsveje øge latenstiden. Planlæg derfor store VM'er i første omgang ud fra lokal RAM-kapacitet og kernefordeling, i stedet for blot at se på summen af alle kerner og den samlede RAM.

Reserveret RAM sikrer, at den lovede hukommelseskapacitet ikke blot skyldes en optimistisk overbooking. Derudover begrænser Storage-QoS IOPS, gennemstrømning eller køer pr. VM, så en sikkerhedskopiering, en databaseimport eller en forkert konfigureret gæst ikke blokerer den fælles NVMe-pool. Fastlæg overbookingsgrænser separat for CPU, RAM og storage: En bæredygtig CPU-kvote gør ikke en node robust, hvis dens storage allerede skaber lange ventetider under spidsbelastning.

Til fortrolige virtuelle maskiner tilbyder begge platforme funktioner, der går ud over almindelig virtualisering. AMD dokumenterer EPYC 9005 SEV, SEV-ES og SEV-SNP; SEV-SNP supplerer mekanismer til beskyttelse mod bestemte sidekode- og hukommelsestildelingsangreb. Intel beskriver TDX som en teknologi, hvor gæstoperativsystemet og VM-applikationerne isoleres fra cloud-værten, hypervisoren og andre VM'er på platformen.

Sådanne funktioner gør hverken en AMD EPYC- eller en Intel Xeon-server automatisk mere sikker. For Intel TDX skal man kontrollere, om processorer understøttes, om der er passende DIMM-konfiguration, og hvilken konkret OEM- eller ODM-platform der er tale om; de dokumenterede DIMM-specifikationer kan variere afhængigt af platformens implementering. Desuden forudsætter anvendelsen et afstemt samspil mellem firmware, hypervisor, kerne, gæstoperativsystem og driftsprocesser. Kontroller desuden nøglens livscyklus, attestering, gendannelse og overvågning. Uden disse processer kan en aktiveret hardwarefunktion ikke fuldt ud opfylde en kundes sikkerhedskrav.

Fejlkilder ved sammenligning og drift

En pålidelig sammenligning starter med systemer af samme størrelse. En server med to sokler må ikke sammenlignes med et system med én sokkel, hvis indkøbsspørgsmålet vedrører en platformsklasse. Notér for hver test CPU-model, antal sokler, aktive kerner, RAM-mængde og DIMM-konfiguration. Kun på den måde kan man se, om et resultat skyldes arkitekturen, ekstra hardware eller en afvigende konfiguration.

Også uensartet hukommelse og uensartet I/O forvrider konklusionerne. Forskellige DDR5-kanalindstillinger, NVMe-generationer, RAID-konfigurationer, netværkskort eller BIOS-energiprofiler ændrer gennemstrømningen og latenstiderne betydeligt. AMD påpeger for EPYC 9005, at den konkrete I/O-konfiguration afhænger af platformen og bundkortet; den dokumenterede grænsefladekapacitet er derfor ingen garanti for anvendelsen.

Mange PCIe-baner gør det ganske vist lettere at tilslutte flere NVMe-drev og hurtige netværkskort direkte. De garanterer dog ikke lav latenstid i databasen: Køer i lagringssystemet, controller-firmware, replikering, databaseparametre og arbejdsmængden i RAM er stadig afgørende. For lagringsnære arkitekturer supplerer denne artikel Webhosting til IoT-platforme perspektivet på netværksforsinkelse, segmentering og datalagringsstier.

Isolerede boost-taktfrekvenser er heller ikke en benchmark for hosting. AMD definerer den maksimale boost som den frekvens, en enkelt kerne kan nå under normale serverforhold; ved parallel kontinuerlig belastning gælder der andre termiske og energimæssige rammebetingelser. Man bør derfor måle responstidens percentiler og gennemstrømning under repræsentative samtidighedsforhold i stedet for at drage konklusioner om en hel nodes ydeevne ud fra en enkelt klokfrekvensangivelse.

TDP er trods alt ikke en måling af serverens faktiske strømforbrug. For at kunne lave omkostningsanslag skal du have måleværdier for det komplette system med den valgte RAM, lagerplads, netværksbelastning og energiprofil. De Sammenlignelighed Offentliggørelse af resultater kræver desuden fuldstændige systemoplysninger; SPEC behandler resultaterne udtrykkeligt som resultater fra komplette systemer, ikke fra enkelte processorer.

Træffe beslutninger om indkøb på baggrund af målbare krav

Dokumentér først belastningsprofilen: antal og størrelse af klienter, typisk og maksimal samtidighed, andel af PHP eller applikationer, databaseforespørgsler, cache-hit-procent, RAM pr. instans samt I/O- og netværksspidsbelastninger. Dette resulterer ikke i en abstrakt rangliste, men i et kravkatalog. Først dette viser, om det er en høj kerne-tæthed, korte svartider for de enkelte arbejdsprocesser eller en særligt omfattende storage-forbindelse, der er afgørende.

Bestem derefter, om du vil udvide en eksisterende platform, vurdere brugte eller lagrede systemer eller anskaffe en helt ny serverkonfiguration. For EPYC 9005 og Xeon 6 skal tilgængelighed, OEM-godkendelser, firmwarevedligeholdelse og planlægning af reservedele for den konkrete servermodel undersøges. Betegnelsen for CPU-familien alene er ikke i sig selv bevis for leverbarhed eller validering af det ønskede RAM-, lager- og netværksudstyr.

Sammenlign derefter de konkrete SKU’er, herunder sokkeltopologi og serverplatform. For AMD EPYC 9005 skal kernevarianten, modellen samt den planlagte DDR5- og PCIe-udvidelse undersøges. Serien omfatter Zen-5- og Zen-5c-modeller, hvis egenskaber ikke kan sidestilles generelt. For Intel Xeon 6 skal der især skelnes mellem P-Core- og E-Core-varianter, da de forfølger forskellige mål med hensyn til ydelse pr. kerne og kerne tæthed.

Kontroller udvidelsen som en komplet stykliste: valideret DIMM-konfiguration, lokal RAM pr. NUMA-node, antal og tilslutning af NVMe-drev, NIC’er, PCIe-switche samt køling og strømforsyninger. En EPYC-9005-hosting-knudepunkt Det er indlysende, hvis en konkret tilgængelig konfiguration leverer den krævede kombination af kerner, hukommelseskanaler og I/O. Dette er en egnethedsvurdering af den valgte SKU og serverplatform, ikke en generel ydelsesfordel i forhold til Intel Xeon.

En Intel Xeon 6-server med E-kerner kan være et fornuftigt valg til mange velafgrænsede, uafhængige arbejdsbelastninger. P-kerne-modeller er snarere et alternativ, når enkelte applikationer kræver høj ydeevne pr. kerne, eller når relevante vektor- og matrixfunktioner spiller en rolle. Intel nævner AVX-512 og AMX i forbindelse med Xeon 6 P-kerner; om disse funktioner er til hjælp, afhænger dog af den anvendte software og dens konkrete implementering.

Udfør en reproducerbar test med dine egne billeder, konfigurationer og realistiske datamængder, inden du afgiver bestillingen. Udover antallet af anmodninger pr. sekund skal du også registrere fejlprocenten, svartidspercentiler, ventetider i databasen, lagringsforsinkelser samt systemets adfærd ved parallelle sikkerhedskopieringer eller nedbrud. Det er nødvendigt med fuldstændige oplysninger om hardware og software, så senere beslutninger forbliver gennemsigtige.

En Prøvedrift Det er hensigtsmæssigt, hvis den planlagte klienttæthed, nye hypervisor-funktioner, et uvant NVMe-design eller energikostnader har stor indflydelse på beregningen. Brug i den forbindelse en begrænset, repræsentativ kunde- eller testgruppe med klare ressourcebegrænsninger. Først efter at have observeret spidsbelastninger, kapacitetsreserver og driftsforløb kan ekstrapolering, indkøb og udrulning begrundes fagligt.