Meer as 'n miljard unieke IP-adresse gaan elke dag deur die Cloudflare-netwerk; dit dien meer as 11 miljoen HTTP-versoeke per sekonde; sy is binne 100 ms van 95% van die internetbevolking. Ons netwerk strek oor 200 stede in meer as 90 lande, en ons span ingenieurs het 'n uiters vinnige en betroubare infrastruktuur gebou.
Ons is baie trots op ons werk en is daartoe verbind om te help om die internet 'n beter en veiliger plek te maak. Cloudflare se hardeware-ingenieurs het 'n diepgaande begrip van bedieners en hul komponente om die beste hardeware te verstaan en te kies om die werkverrigting daarvan te maksimeer.
Ons sagtewarestapel hanteer hoë-lading rekenaars en is hoogs SVE-afhanklik, wat vereis dat ons ingenieurs Cloudflare se doeltreffendheid en betroubaarheid voortdurend op elke vlak van die stapel moet optimaliseer. Aan die bedienerkant is die maklikste manier om verwerkingskrag te verhoog deur SVE-kerne by te voeg. Hoe meer kerne 'n bediener kan pas, hoe meer data kan dit verwerk. Dit is vir ons belangrik, want die verskeidenheid van ons produkte en kliënte groei met verloop van tyd, en die groei van versoeke vereis verhoogde werkverrigting van bedieners. Om hul werkverrigting te verhoog, moes ons die digtheid van die kerns verhoog - en dit is presies wat ons bereik het. Hieronder verskaf ons gedetailleerde data oor verwerkers vir bedieners wat ons sedert 2015 ontplooi het, insluitend die aantal kerns:
-
Gen 6
Gen 7
Gen 8
Gen 9
Aan die slag
2015
2016
2017
2018
CPU
Intel Xeon E5-2630 v3
Intel Xeon E5-2630 v4
Intel Xeon Silver 4116
Intel Xeon Platinum 6162
Fisiese kerne
X 2 8
X 2 10
X 2 12
X 2 24
TDP
2 x 85W
2 x 85W
2 x 85W
2 x 150W
TDP per kern
10.65W
8.50W
7.08W
6.25W
In 2018 het ons 'n groot sprong gemaak in die totale aantal kerns per bediener met Gen 9. Die omgewingsimpak is met 33% verminder in vergelyking met die 8ste generasie, wat ons die geleentheid bied om volume en rekenaarkrag per rek te verhoog. Ontwerpvereistes vir hitteafvoer (, TDP) word genoem om te beklemtoon dat ons energiedoeltreffendheid ook mettertyd toegeneem het. Hierdie aanwyser is vir ons belangrik: eerstens wil ons minder koolstof in die atmosfeer vrystel; tweedens wil ons die energie van die datasentrums ten beste gebruik. Maar ons weet dat ons iets het om na te streef.
Ons hoofbepalende maatstaf is die aantal versoeke per watt. Ons kan die aantal versoeke per sekonde verhoog deur kerns by te voeg, maar ons moet binne ons kragbegroting bly. Ons word beperk deur die datasentrum-kraginfrastruktuur, wat saam met ons geselekteerde kragverspreidingsmodules vir ons 'n sekere boonste limiet vir elke bedienerrek gee. Die byvoeging van bedieners by 'n rek verhoog kragverbruik. Bedryfskoste sal aansienlik styg as ons die per-rak-energielimiet oorskry en nuwe rakke moet byvoeg. Ons moet verwerkingskrag verhoog terwyl ons binne dieselfde kragverbruikreeks bly, wat versoeke per watt, ons sleutelmetriek, sal verhoog.
Soos jy dalk geraai het, het ons energieverbruik noukeurig bestudeer in die ontwerpstadium. Die tabel hierbo toon dat ons nie tyd moet mors om meer energiehonger SVE's te ontplooi as die TDP per kern hoër is as die huidige generasie nie - dit sal ons metrieke, versoeke per watt, negatief beïnvloed. Ons het die gereed-om-te gebruik stelsels vir ons generasie X op die mark noukeurig bestudeer en 'n besluit geneem. Ons beweeg van ons 48-kern Intel Xeon Platinum 6162 dubbelsok-ontwerp na 'n 48-kern AMD EPYC 7642 enkelsok-ontwerp.
-
Intel
AMD
CPU
Xeon Platinum 6162
EPYC 7642
mikroargitektuur
"Skylake"
"Zen 2"
Kodenaam
Skylake SP
"Rome"
Tegniese proses
14nm
7nm
kerne
X 2 24
48
frekwensie
1.9 GHz
2.4 GHz
L3 Cache/sok
24 x 1.375 MiB
16 x 16 MiB
Geheue/sok
6 kanale, tot DDR4-2400
8 kanale, tot DDR4-3200
TDP
2 x 150W
225W
PCIe/sok
48 bane
128 bane
ISA
x86-64
x86-64
Uit die spesifikasies is dit duidelik dat die skyfie van AMD ons in staat sal stel om dieselfde aantal kerne te behou terwyl die TDP verlaag word. Die 9de generasie het 'n TDP per kern van 6,25 W gehad, en die Xde generasie sal 4,69 W wees. Met 25% verminder. Danksy die verhoogde frekwensie, en miskien 'n eenvoudiger ontwerp met een sok, kan aanvaar word dat die AMD-skyfie in die praktyk beter sal presteer. Ons is tans besig met verskeie toetse en simulasies om te sien hoeveel beter AMD sal presteer.
Kom ons let vir eers daarop dat TDP 'n vereenvoudigde maatstaf is van die vervaardiger se spesifikasies, wat ons in die vroeë stadiums van bedienerontwerp en SVE-keuse gebruik het. ’n Vinnige Google-soektog onthul dat AMD en Intel verskillende benaderings het om TDP te definieer, wat die spesifikasie onbetroubaar maak. Werklike SVE-kragverbruik, en nog belangriker bedienerkragverbruik, is wat ons regtig gebruik wanneer ons ons finale besluit neem.
Ekosisteem gereedheid
Om ons reis na die keuse van ons volgende verwerker te begin, het ons na 'n wye reeks SVE's van verskillende vervaardigers gekyk wat goed pas by ons sagtewarestapel en dienste (geskryf in C, LuaJIT en Go). Ons het reeds 'n stel gereedskap om spoed te meet in detail beskryf . In hierdie geval het ons dieselfde stel gebruik - dit stel ons in staat om die doeltreffendheid van die SVE binne 'n redelike tyd te evalueer, waarna ons ingenieurs kan begin om ons programme by 'n spesifieke verwerker aan te pas.
Ons het 'n verskeidenheid verwerkers getoets met 'n verskeidenheid kerntellings, soktellings en frekwensies. Aangesien hierdie artikel handel oor hoekom ons op die AMD EPYC 7642 besluit het, fokus alle kaarte in hierdie blog op hoe AMD-verwerkers presteer in vergelyking met die Intel Xeon Platinum 6162 vanaf .
Die resultate stem ooreen met metings van 'n enkele bediener met elke verwerkervariant - dit wil sê met twee 24-kern verwerkers van Intel, of met een 48-kern verwerker van AMD (bediener vir Intel met twee voetstukke en bediener vir AMD EPYC met een) . In die BIOS stel ons die parameters wat ooreenstem met die lopende bedieners. Dit is 3,03 GHz vir AMD en 2,5 GHz vir Intel. Om dit baie te vereenvoudig, verwag ons dat AMD met dieselfde aantal kerns 21% beter as Intel sal vaar.
Kriptografie
Lyk belowend vir AMD. Dit vaar 18% beter op publieke sleutel kriptografie. Met 'n simmetriese sleutel verloor dit vir die AES-128-GCM-enkripsie-opsies, maar presteer oor die algemeen vergelykbaar.
Kompressie
Op randbedieners druk ons baie data saam om bandwydte te bespaar en die spoed van inhoudlewering te verhoog. Ons gee die data deur die C-biblioteke zlib en brotli. Alle toetse is op die blog.cloudflare.com HTML-lêer in die geheue uitgevoer.
AMD het gemiddeld 29% gewen met gzip. In die geval van brotli is die resultate selfs beter op toetse met kwaliteit 7, wat ons vir dinamiese kompressie gebruik. Op die brotli-9-toets is daar 'n skerp daling - ons verduidelik dit deur die feit dat Brotli baie geheue verbruik en die kas oorloop. AMD wen egter met 'n groot marge.
Baie van ons dienste is in Go geskryf. In die volgende grafieke kontroleer ons die spoed van kriptografie en kompressie in Go with RegExp op 32 KB-lyne deur die stringe-biblioteek te gebruik.
Gaan kriptografie
Gaan kompressie
Gaan Regexp
Gaan Strings
AMD presteer beter in alle toetse met Go behalwe ECDSA P256 Sign, waar dit 38% agter was - wat vreemd is, aangesien dit 24% beter in C gevaar het. Dit is die moeite werd om uit te vind wat daar aangaan. In die algemeen wen AMD nie veel nie, maar toon steeds die beste resultate.
LuaJIT
Ons gebruik dikwels LuaJIT op die stapel. Dit is die gom wat al die dele van Cloudflare bymekaar hou. En ons is bly dat AMD ook hier gewen het.
Oor die algemeen toon die toetse dat die EPYC 7642 beter presteer as twee Xeon Platinum 6162. AMD verloor op 'n paar toetse - byvoorbeeld AES-128-GCM en Go OpenSSL ECDSA-P256 Sign - maar wen op al die ander, gemiddeld van 25%.
Werklading Simulasie
Na ons vinnige toetse het ons die bedieners deur 'n ander stel simulasies laat loop waarin 'n sintetiese las op die sagteware randstapel toegepas word. Hier simuleer ons 'n scenario-werklading met verskillende soorte versoeke wat in werklike werk teëgekom kan word. Versoeke verskil in datavolume, HTTP- of HTTPS-protokolle, WAF-bronne, Werkers en baie ander veranderlikes. Hieronder is 'n vergelyking van die deurset van die twee SVE's vir die tipe versoeke wat ons die meeste teëkom.
Die resultate in die grafiek word gemeet teen die basislyn van 9de generasie Intel-gebaseerde masjiene, genormaliseer tot 'n waarde van 1,0 op die x-as. As ons byvoorbeeld eenvoudige 10 KiB-versoeke oor HTTPS neem, kan ons sien dat AMD 1,5 keer beter doen as Intel in terme van versoeke per sekonde. AMD het gemiddeld 34% beter as Intel vir hierdie toetse gevaar. As in ag geneem word dat die TDP vir 'n enkele AMD EPYC 7642 225 W is, en vir twee Intel-verwerkers 300 W is, blyk dit dat AMD in terme van "versoeke per watt" 2 keer beter resultate as Intel toon!
Op hierdie stadium het ons reeds duidelik geleun na die enkelsok-opsie vir die AMD EPYC 7642 as ons toekomstige Gen X-SVE's. Ons was baie geïnteresseerd om te sien hoe die AMD EPYC-bedieners in die werklike wêreld sou werk, en ons het dadelik verskeie gestuur bedieners na sommige van datasentrums.
Regte werk
Die eerste stap was natuurlik om die bedieners voor te berei vir werk in werklike omstandighede. Alle masjiene in ons vloot werk met dieselfde prosesse en dienste, wat 'n uitstekende geleentheid bied om prestasie korrek te vergelyk. Soos die meeste datasentrums, het ons verskeie generasies bedieners wat ontplooi is, en ons versamel ons bedieners in groepe sodat elke klas bedieners van ongeveer dieselfde generasies bevat. In sommige gevalle kan dit lei tot herwinningskurwes wat tussen trosse verskil. Maar nie by ons nie. Ons ingenieurs het SVE-benutting vir alle generasies geoptimaliseer, sodat ongeag of 'n spesifieke masjien se SVE 8 kerns of 24 het, SVE-benutting oor die algemeen dieselfde is as die res.
Die grafiek illustreer ons opmerking oor die ooreenkoms van gebruik – daar is geen noemenswaardige verskil tussen die gebruik van AMD SVE's in Gen X generasie bedieners en die gebruik van Intel verwerkers in Gen 9 generasie bedieners. Dit beteken dat beide toets- en basislynbedieners gelyk gelaai word . Groot. Dit is presies waarna ons streef in ons bedieners, en ons het dit nodig vir 'n regverdige vergelyking. Die twee grafieke hieronder toon die aantal versoeke wat deur een SVE-kern en alle kerne op die bedienervlak verwerk is.
Versoeke per kern
Versoeke aan die bediener
Dit kan gesien word dat AMD gemiddeld 23% meer versoeke verwerk. Glad nie sleg nie! Ons het dikwels op ons blog geskryf oor maniere om die werkverrigting van Gen 9 te verhoog. En nou het ons dieselfde aantal kerne, maar AMD doen meer werk met minder krag. Dit is onmiddellik duidelik uit die spesifikasies vir die aantal kerns en TDP dat AMD groter spoed met groter energiedoeltreffendheid bied.
Maar soos ons reeds genoem het, is TDP nie 'n standaardspesifikasie nie en dit is nie dieselfde vir alle vervaardigers nie, so kom ons kyk na die werklike energieverbruik. Deur die bediener se energieverbruik parallel met die aantal versoeke per sekonde te meet, het ons die volgende grafiek verkry:
Gebaseer op versoeke per sekonde per watt bestee, is Gen X-bedieners wat op AMD-verwerkers werk, 28% meer doeltreffend. Mens kan meer verwag, aangesien AMD se TDP 25% laer is, maar daar moet onthou word dat TDP 'n dubbelsinnige eienskap is. Ons het gesien dat AMD se werklike kragverbruik amper identies is aan die genoemde TDP by frekwensies wat baie hoër is as die basis; Intel het dit nie. Dit is nog 'n rede waarom TDP nie 'n betroubare skatting van energieverbruik is nie. SVE's van Intel in ons Gen 9-bedieners is geïntegreer in 'n multi-node-stelsel, terwyl SVE's van AMD in standaard 1U-vormfaktorbedieners werk. Dit is nie ten gunste van AMD nie, aangesien multinode-bedieners groter digtheid moet bied met minder kragverbruik per nodus, maar AMD het Intel steeds verbygesteek wat kragverbruik per nodus betref.
In die meeste vergelykings oor spesifikasies, toetssimulasies en werklike werkverrigting het die 1P AMD EPYC 7642-konfigurasie aansienlik beter gevaar as die 2P Intel Xeon 6162. In sommige toestande kan AMD tot 36% beter presteer, en ons glo dat deur te optimaliseer hardeware en sagteware, ons kan hierdie verbetering op 'n deurlopende basis bereik.
Dit blyk dat AMD gewen het.
Bykomende grafieke toon gemiddelde latency en p99-latency wat NGINX oor 'n 24-uur-tydperk loop. Prosesse op AMD het gemiddeld 25% vinniger geloop. Op p99 loop dit 20-50% vinniger na gelang van die tyd van die dag.
Gevolgtrekking
Cloudflare se hardeware en prestasie-ingenieurs doen 'n aansienlike hoeveelheid toetsing en navorsing om die beste bedienerkonfigurasie vir ons kliënte te bepaal. Ons is mal daaroor om hier te werk, want ons kan groot probleme soos hierdie oplos, en ons kan jou help om jou probleme op te los met dienste soos bedienerlose randrekenaars en 'n verskeidenheid sekuriteitsoplossings soos Magic Transit, Argo Tunnel en DDoS-beskerming. . Alle bedieners in die Cloudflare-netwerk is gekonfigureer om betroubaar te werk, en ons probeer altyd om elke volgende generasie bedieners beter as die vorige een te maak. Ons glo dat die AMD EPYC 7642 die antwoord is wanneer dit by Gen X-verwerkers kom.
Deur Cloudflare Workers te gebruik, ontplooi ontwikkelaars hul toepassings op ons groeiende netwerk regoor die wêreld. Ons is trots om ons kliënte te laat fokus op die skryf van kode terwyl ons fokus op sekuriteit en betroubaarheid in die wolk. En vandag is ons selfs meer bly om aan te kondig dat hul werk ontplooi sal word op ons Gen X generasie bedieners wat tweede generasie AMD EPYC verwerkers gebruik.
EPYC 7642 verwerkers, kodenaam "Rome" [Rome]
Deur AMD se EPYC 7642 te gebruik, kon ons ons werkverrigting verhoog en dit makliker maak om ons netwerk na nuwe stede uit te brei. Rome is nie in 'n dag gebou nie, maar dit sal binnekort nader aan baie van julle wees.
In die afgelope paar jaar het ons met baie x86-skyfies van Intel en AMD geëksperimenteer, sowel as verwerkers van ARM. Ons verwag dat hierdie SVE-vervaardigers in die toekoms sal voortgaan om saam met ons te werk sodat ons almal saam 'n beter internet kan bou.
Bron: will.com