Delt hosting: Hvornår er hurtige CPU’er en fordel, selvom de har få kerner?

Forskellen mellem kerner, tråde og CPU-tid

En fysisk kerne er en regneenhed i processoren. Operativsystemet opfatter derimod logiske processorer som eksekverbare enheder: Ved samtidig multithreading kan flere af disse dele ressourcerne på en fysisk kerne. Antallet af disse giver derfor ikke umiddelbart et billede af, hvor mange uafhængige kerner der er til rådighed for en hostingkonto.

Ved shared hosting deler flere konti en servers hardware. Et abonnement kan begrænse, hvor meget CPU-tid en kontos processer må bruge inden for et bestemt tidsrum. Dette CPU-tidsbudget er noget andet end en forpligtelse til udelukkende at benytte en fysisk kerne. Linux-cgroups er et muligt teknisk grundlag for sådanne begrænsninger, men ikke den eneste mulige implementering.

Hvis der f.eks. står „en vCore“ eller „100 procent CPU“ i prisplanen, bør du tjekke udbyderens definition. Angivelsen kan beskrive et beregningstidsbudget uden at reservere en bestemt kerne permanent. Det fremgår heller ikke af det samlede antal kerner på værtserveren, hvor meget ydeevne en enkelt konto faktisk må bruge samtidigt.

Med »samtidighed« menes her, hvor mange forespørgsler eller processer der kan behandles parallelt. Det afhænger blandt andet af procesgrænser, hukommelse og tilgængeligt CPU-budget. CloudLinux kan anvende egne ressourcegrænser til dette formål; du skal spørge udbyderen, om et abonnement bruger denne teknik, og hvordan den er konfigureret.

Ressourcebegrænsning og sikkerhedsisolering har forskellige formål: En begrænsning styrer forbruget, mens en isolering har til formål at begrænse adgangen mellem miljøer. Den Oversigt over CloudLinux Site Isolation og CageFS forklarer de relevante sikkerhedsmekanismer; dette medfører i sig selv ingen bestemt CPU-tildeling.

Hvorfor GHz alene ikke er afgørende

Klokfrekvensen angiver, hvor mange taktscyklusser en processor udfører pr. sekund. En højere klokfrekvens kan fremskynde CPU-afhængige opgaver, men siger ikke i sig selv noget om, hvor meget et websted drager fordel af den. Forskellige processorarkitekturer udfører forskellige mængder arbejde pr. takt; også den konkrete programkode har indflydelse på resultatet.

Til den Single-core-ydeevne Cache og hukommelsesadfærd spiller desuden en rolle. Hvis en proces ofte skal vente på data, kan en højere frekvens have mindre betydning end ved en beregning, hvor dataene allerede er hurtigt tilgængelige. En sammenligning, der udelukkende baseres på GHz, udelader disse forskelle og kan ikke erstatte en applikationsbaseret benchmark.

Et eksempel på et begrænset datablad er AMD EPYC 4564P: For denne model angiver AMD 16 kerner, 32 tråde, en basisfrekvens på 4,5 GHz og en maksimal boost-frekvens på op til 5,7 GHz. Disse oplysninger beskriver processoren, ikke ydeevnen for et bestemt hostingabonnement.

Der Maksimal boost er hverken en garanteret konstant værdi eller den frekvens, der til enhver tid er til stede på alle kerner. Produktdataene viser heller ikke, hvor hurtigt et bestemt shared hosting-abonnement behandler en WordPress- eller PHP-forespørgsel. Her spiller ikke kun hardwaren, men også konfigurationen, udnyttelsesgraden og abonnementsbegrænsningerne en rolle.

Når udbydere med højfrekvent CPU-hosting reklamerer, så spørg derfor efter den konkrete processormodel og det tilgængelige ressourcebudget. For at kunne foretage meningsfulde ydelses sammenligninger er der desuden brug for oplysninger om softwareversion, serverkonfiguration, arbejdsbelastning og testbetingelser. Uden disse oplysninger kan en annonceret GHz-værdi ikke pålideligt omsættes til en kortere responstid.

PHP-forespørgsler og parallel behandling

Ved en typisk synkron forespørgsel behandler en PHP-worker de enkelte trin i sit PHP-arbejde hovedsageligt efter hinanden. En hurtigere CPU kan forkorte denne del, hvis den rent faktisk er beregningsintensiv. Hvis workeren derimod primært venter på en database eller en ekstern tjeneste, er fordelen ved højere processorkraft begrænset i forhold til denne ventetid.

Søgeformuleringen php single core Det betyder derfor ikke, at et helt websted kun kan bruge én kerne. Flere forespørgsler kan behandles parallelt af flere arbejdsprocesser; også webserveren og databasen kan arbejde samtidigt. Det afgørende er, hvor meget af dette parallelle arbejde de tilgængelige ressourcer og den pågældende konfiguration tillader.

Begrænset ved PHP-FPM pm.max_children antallet af forespørgsler, som en pool kan behandle samtidigt. Når grænsen er nået, kan yderligere forespørgsler ikke straks behandles af en anden worker i denne pool. Grænsen siger dog ikke noget om, hvor mange besøgende der samlet set kan benytte et websted.

Die Processtyring PHP-FPM har tre driftsformer: static holder et fast antal arbejdere klar. dynamic tilpasser antallet til efterspørgslen ud fra konfigurationen; ondemand starter arbejdsprocesser efter behov. Den valgte driftsform bestemmer dermed også, hvornår processer er klar eller genstartes.

Flere arbejdsprocesser giver ikke automatisk mere CPU-tid. De kræver desuden arbejdshukommelse og kan, hvis de kører parallelt, sammen nå op på en kontogrænse. For at vurdere en CPU til delt hosting Antallet af arbejdere og ressourcebudgettet hører derfor sammen. Ikke alle abonnementer bruger PHP-FPM eller giver kunderne mulighed for selv at ændre indstillingerne.

CPU-kvote ved parallel belastning

En CPU-kvote fastlægger, hvor meget regnetid en procesgruppe må bruge inden for et bestemt tidsrum. Under Linux beskriver cgroup v2 cpu.max dette budget og den tilhørende periode. Kvoten reserverer således ikke automatisk en eksklusiv fysisk kerne: Den begrænser gruppens samlede tilgængelige CPU-tid.

Illustrativt regneeksempel, ikke en måling: En gruppe får 100 millisekunder CPU-tid pr. 100 millisekunders periode. Dette svarer i gennemsnit til beregningstiden for en fuldt udnyttet logisk processor. Hvis to processer kører samtidigt på to tilgængelige logiske processorer, kan de teoretisk set opbruge det fælles budget efter ca. 50 millisekunder vægtid.

Når budgettet er opbrugt, kan processerne bremses indtil næste periode. De to worker-processer har altså ikke hver især et eget budget på 100 millisekunder. Om og hvornår de rent faktisk kører parallelt, afhænger blandt andet af scheduleren, de tilgængelige CPU’er og deres adfærd; eksemplet giver ingen konkret forudsigelse om responstiden.

Til undersøgelsen indstiller cgroup v2 til cpu.stat blandt andet tællere til Neddrosling klar. Hvis de stiger under en repræsentativ belastningsfase, er det et tegn på, at kvoten er opbrugt. En enkelt måleraflæsning forklarer dog ikke, hvilken forespørgsel der var tale om, eller om der ud over denne findes yderligere flaskehalse.

Du skal afklare med udbyderen, om disse filer er tilgængelige i den valgte pakke og relevante for hjemmesiden. Shared hosting kan anvende andre mekanismer: CloudLinux dokumenterer for eksempel egne LVE-grænser for CPU og andre ressourcer. Ud fra Linux-eksemplet kan man derfor hverken udlede den konkrete konfiguration eller, hvordan hver enkelt hostingkonto fungerer.

CMS, webshop og baggrundsopgaver

Når der er tale om en CMS-side uden cache, udfører serveren applikationslogik ved hentningen og indhenter de nødvendige data. Hvis en stor del af behandlingen udgøres af CPU-arbejde, kan en højere ydeevne pr. kerne forkorte dette afsnit. Det gælder f.eks. for ressourcekrævende beregninger i PHP-koden, men ikke nødvendigvis for den samlede tid, indtil siden er færdig.

Hvis den samme forespørgsel derimod hovedsageligt afhænger af en databaseforespørgsel eller et eksternt API, kan PHP-processen i denne periode kun i begrænset omfang drage fordel af en hurtigere CPU. Afgørende for beslutningen er derfor fordelingen af den serversidige svartid: Hvor meget går der med beregninger, og hvor meget går der med at vente på andre tjenester?

En webshop viser, hvorfor svaret på dette spørgsmål kan variere fra side til side. Offentlige produktsider kan under de rette betingelser gemmes som et færdigt svar. En cache-hit kan undgå, at PHP skal behandle dataene på ny; indkøbskurven og kassen skal derimod ofte tage højde for individuelle data og forbliver dynamiske.

Mange samtidige checkout-anmodninger kan derfor belaste worker-ressourcerne eller CPU-kapaciteten mere end et tilsvarende antal opkald til sider fra cachen. Besøgstal alene giver ikke et fuldstændigt billede af denne belastning: Det afgørende er, hvilke slutpunkter der anmodes om samtidigt, og hvor ofte cachen træffer. I PHP-FPM begrænser pool-indstillingen desuden pm.max_children antallet af forespørgsler, der behandles samtidigt.

En beregningskrævende import i backend kan til gengæld drage fordel af hurtigere individuel behandling. Hvis den kører sideløbende med besøgendeforespørgsler, kan processerne muligvis konkurrere om det samme CPU-tidsbudget. Om en cron-opgave eller en import faktisk er tildelt den samme begrænsede gruppe, afhænger af abonnementstypen og dens opsætning; spørg udbyderen, inden du træffer en beslutning om kapacitet.

For at kunne foretage en meningsfuld sammenligning bør du betragte disse arbejdsbelastninger hver for sig: en typisk dynamisk forespørgsel, en fase med flere samtidige forespørgsler og eventuelt import under løbende drift. På den måde kan du bedre se, om hastigheden på et enkelt trin eller den samlede tilgængelige kapacitet er den vigtigste faktor.

Sammenligning af observationer og flaskehalse

Et langsomt svar er ikke i sig selv en årsag. Den følgende oversigt sammenholder typiske observationer med muligheder, der kan undersøges nærmere. Den tager især højde for CPU-tidsgrænser, det begrænsede antal workere i PHP-FPM og forskellen mellem gemt PHP-kode og et allerede genereret svar.

Hver tabelrække er en Hypotese, ingen endelig diagnose. Langsomme svar under parallelbehandling kan for eksempel hænge sammen med en CPU-begrænsning, men kan også skyldes optagede arbejdsprocesser eller en ventende database. Undersøg derfor om muligt flere signaler på samme tid og for den samme arbejdsbelastning, i stedet for at konkludere, at der skal skiftes takst ud fra et enkelt symptom.

Ved udvurderingen skal du adskille Svartid En forespørgsel om gennemstrømning: Et hurtigere svar på en enkelt forespørgsel betyder ikke automatisk, at der ved høj samtidighed behandles tilsvarende flere forespørgsler pr. sekund. Omvendt kan et system opnå en god gennemstrømning og alligevel lade enkelte forespørgsler vente længere.

Den oplevede indlæsningstid for en side kan heller ikke sidestilles med svartiden på serversiden. Efter svaret kan der for eksempel indlæses yderligere ressourcer, som behandles i browseren. En CPU-opgradering i hostingløsningen vedrører kun den pågældende del på serversiden; for at sikre en retfærdig sammenligning bør cache-tilstanden, den anmodede side og paralleliteten forblive uændrede.

Når det gælder cachen, er det desuden værd at skelne mellem begreberne: OPcache gemmer kompileret PHP-kode og kan dermed undgå, at den skal kompileres på ny. En sidecache gemmer derimod et genereret svar. Et hurtigt cache-hit beviser derfor hverken, at dynamiske forespørgsler har tilstrækkelig CPU-kapacitet, eller at OPcache erstatter applikationens logik.

At genkende begrænsninger og ventetider

Start diagnosen med forespørgsler, der er typiske for din hjemmeside: for eksempel en offentlig CMS-side, en søgning og – i tilfælde af en webshop – betalingsprocessen. Notér, om det pågældende svar stammer fra sidecachen. Sammenlign derefter enkelte sidevisninger og et antal samtidige forespørgsler, der er repræsentativt for dit projekt, i stedet for udelukkende at se på det samlede antal besøgende.

Adskil om muligt CPU-tid applikationens samlede responstid og ventetiderne på databasen eller eksterne tjenester. Hvis CPU-andelen er lille, kan en hurtigere processor kun forkorte en tilsvarende begrænset del af opkaldet. Hvis du mangler egnede måleværdier, skal du spørge udbyderen om tilgængelige logfiler, målinger eller en passende analyse.

Undersøg ved parallel belastning, om de tilgængelige workere er fuldt udnyttet, og om grænsetællerne stiger. Begrænset ved PHP-FPM pm.max_children de forespørgsler fra en pool, der behandles samtidigt; om du kan se denne værdi eller udnyttelsesgraden, afhænger af din abonnementstype. Linux-cgroup-v2-systemer kan i cpu.stat blandt andet vise begrænsningstællere. En stigende tæller er en anledning til at undersøge CPU-budgettet og måleperioden nærmere.

Hvis SSH og den pågældende fil er tilgængelige, viser cat /proc/self/cgroup den kaldende process’ cgroup-tilknytning. Det betyder dog ikke, at webforespørgsler kører i samme gruppe. Afklar stier, rettigheder og fortolkning med udbyderen; fejlkoder kan heller ikke generelt tilknyttes en bestemt grænse for hvert enkelt shared hosting-system.

Tjek cachen og sammenlign priser

Tjek først, hvilke offentlige sider der sikkert kan gemmes som et fuldstændigt svar. En Sidecache kan undgå gentagen dynamisk behandling ved et hit. Personligt tilpasset indhold, indkøbskurv og kasse kræver derimod en passende cachestrategi, så besøgende ikke får vist fremmede eller forældede data.

En anden tilgang er at reducere arbejdsbyrden ved cache-misses: Undersøg langsomme databaseforespørgsler og fjern unødvendig dynamisk behandling. Når der er tale om en ekstern tjeneste, kan dens responstid være afgørende; i så fald bør du først se nærmere på dette opkald i stedet for at antage, at CPU'en er årsagen. Hvilken ændring der hjælper, afhænger af den faktisk langsomme sti.

Dette skal adskilles fra OPcache: Den gemmer kompileret PHP-kode, men erstatter hverken en fuldstændig sidecache eller udførelsen af applikationslogikken. Kontroller tilgængeligheden og indstillingerne i web-kørselsmiljøet. CLI har sin egen OPcache-indstilling; et kig på kommandolinjen alene er derfor ikke tilstrækkeligt til at fastslå konfigurationen for webforespørgsler.

Når du sammenligner priser, bør du sammenligne de samme forespørgsler med identiske softwareversioner, sammenlignelige datamængder og en fastlagt cache-tilstand. Gentag sammenligningen med samme parallelitet, og tag højde for de respektive tilgængelige CPU-, worker- og hukommelsesbudgetter. Ellers kan der opstå en forskel på grund af testbetingelserne, uden at det siger noget pålideligt om processorydelsen.

Notér desuden separat, hvor lang tid de enkelte svar tager, og hvor mange forespørgsler der behandles i et givet tidsrum. En takst kan virke billig for et enkelt opkald, men alligevel nå sine grænser ved samtidig belastning. Værdier fra en sammenligning gælder i første omgang kun for den undersøgte applikation og dens betingelser.

En hurtigere CPU eller et større budget?

Hvis en repræsentativ dynamisk forespørgsel hovedsageligt udfører CPU-arbejde, og hverken arbejdsprocesser, hukommelse eller tidsbudget udgør en begrænsning, er højere Pro-Kern-ydelse en plausibel tarifmulighed. Den kan forkorte den beregningsmæssige del af den enkelte forespørgsel. Hvor stor indflydelse dette har på det samlede svar, afhænger dog stadig af applikationen og dens ventetider.

Hvis dataene derimod viser begrænsninger eller overbelastede arbejdsprocesser ved flere samtidige anmodninger, skal du overveje en større Budget for ressourcer. Mere CPU-tid kan være en hjælp, hvis kvotegrænsen er nået; yderligere arbejdsprocesser kræver samtidig tilstrækkelig hukommelse og regnetid. Hvis databasen eller eksterne tjenester udgør flaskehalsen, er et højere CPU-budget i sig selv ikke en pålidelig løsning.

Inden du skifter, er det en god idé at sammenligne med en optimering af den eksisterende installation. En passende sidecache eller en forbedret forespørgsel kan reducere den dynamiske belastning, uden at du straks har brug for en større abonnementsplan. Gentag diagnosen efter en ændring under sammenlignelige forhold, så du kan skelne ændringens effekt fra andre påvirkninger.

En VPS som alternativ til delt hosting giver som regel større indflydelse på software og konfiguration, men medfører også et større ansvar for sikkerhed, opdateringer og kapacitetsplanlægning. Virtuelle CPU’er er ikke eksklusive fysiske kerner, medmindre udbyderen udtrykkeligt har bekræftet dette. Tjek derfor også den konkrete ressourceallokering og kontraktbetingelserne på dette område.

Spørg udbyderen, inden du træffer en beslutning, om processormodellen, definitionen af CPU-tidsbudgettet og håndteringen af belastningsspidser. Afklar desuden, hvilke begrænsninger der gælder for arbejdsprocesser og hukommelse, om baggrundsopgaver deler det samme budget, og hvilke begrænsningstællere du kan se. Først disse oplysninger gør det muligt at vurdere den annoncerede CPU-ydeevne i forhold til netop din abonnementstype.