Delad hosting: När snabba processorer kan vara till hjälp trots få kärnor

Skillnaden mellan kärnor, trådar och CPU-tid

En fysisk kärna är en beräkningsenhet i processorn. Operativsystemet ser däremot logiska processorer som körbara enheter: Vid samtidig multithreading kan flera av dessa dela resurser från en fysisk kärna. Antalet ger därför inte någon direkt indikation på hur många oberoende kärnor som finns tillgängliga för ett webbhotellskonto.

Vid delad hosting delar flera konton på en servers hårdvara. Ett abonnemang kan begränsa hur mycket CPU-tid ett kontos processer får använda under en viss tidsperiod. Detta CPU-tidsbudget är något annat än ett åtagande att exklusivt använda en fysisk kärna. Linux-cgroups är en möjlig teknisk grund för sådana begränsningar, men inte den enda möjliga lösningen.

Om det i prisplanen står till exempel „en vCore“ eller „100 procent CPU“, bör du kontrollera leverantörens definition. Uppgiften kan avse en beräkningstidsbudget utan att en viss kärna reserveras permanent. Det framgår inte heller av det totala antalet kärnor på värdservern hur mycket prestanda ett enskilt konto faktiskt får använda samtidigt.

Med ”parallellitet” avses här hur många förfrågningar eller processer som kan hanteras samtidigt. Det beror bland annat på processgränser, lagringsutrymme och tillgänglig CPU-kapacitet. CloudLinux kan använda egna resursgränser för detta; du måste fråga leverantören om ett abonnemang använder denna teknik och hur den är konfigurerad.

Resursbegränsning och säkerhetsisolering fyller olika syften: En begränsning styr förbrukningen, medan isolering syftar till att begränsa åtkomsten mellan miljöer. Den Översikt över CloudLinux Site Isolation och CageFS förklarar motsvarande säkerhetsmekanismer; detta innebär i sig inte någon specifik CPU-tilldelning.

Varför GHz i sig inte är avgörande

Klockfrekvensen anger hur många klockcykler en processor utför per sekund. En högre klockfrekvens kan påskynda CPU-beroende uppgifter, men säger i sig inte hur mycket en webbplats drar nytta av detta. Olika processorarkitekturer utför olika mycket arbete per klockcykel; även den specifika programkoden påverkar resultatet.

Till Enkärnig prestanda Dessutom spelar cacheminnet och minnesbeteendet en roll. Om en process ofta måste vänta på data kan en högre klockfrekvens ha mindre effekt än vid en beräkning där data redan är snabbt tillgängliga. En jämförelse som enbart baseras på GHz bortser från dessa skillnader och ersätter inte ett applikationsspecifikt prestandatest.

Ett exempel på ett begränsat datablad är AMD EPYC 4564P: För denna modell anger AMD 16 kärnor, 32 trådar, en basklockfrekvens på 4,5 GHz och en maximal boostfrekvens på upp till 5,7 GHz. Dessa uppgifter beskriver processorn, inte prestandan hos ett specifikt webbhotellpaket.

Der Maximal boost är varken ett garanterat konstant värde eller den frekvens som alltid förekommer på alla kärnor. Produktuppgifterna visar inte heller hur snabbt ett visst shared hosting-paket bearbetar en WordPress- eller PHP-förfrågan. För detta spelar inte bara hårdvaran utan även konfigurationen, belastningen och paketets begränsningar en roll.

När leverantörer med högfrekvent CPU-hosting reklamerar, så fråga därför efter den specifika processormodellen och den tillgängliga resursbudgeten. För att prestandajämförelser ska vara meningsfulla krävs dessutom uppgifter om programvaruversion, serverkonfiguration, arbetsbelastning och testförhållanden. Utan dessa uppgifter går det inte att på ett tillförlitligt sätt översätta ett angivet GHz-värde till en kortare svarstid.

PHP-förfrågningar och parallell bearbetning

Vid en typisk synkron förfrågan bearbetar en PHP-arbetare de enskilda stegen i sitt PHP-arbete huvudsakligen i tur och ordning. En snabbare CPU kan förkorta denna del om den faktiskt är beräkningsintensiv. Om arbetaren däremot främst väntar på en databas eller en extern tjänst, är nyttan av högre processorkraft begränsad under denna väntetid.

Sökformuleringen php single core Det innebär därför inte att en hel webbplats endast kan använda en kärna. Flera förfrågningar kan bearbetas parallellt av flera arbetare; även webbservern och databasen kan arbeta samtidigt. Det avgörande är hur mycket av detta parallella arbete som de tillgängliga resurserna och den aktuella konfigurationen tillåter.

Begränsning i PHP-FPM pm.max_children antalet förfrågningar som en pool hanterar samtidigt. Om gränsen nås kan ytterligare förfrågningar inte omedelbart behandlas av en annan arbetare i samma pool. Gränsen säger dock ingenting om hur många besökare som totalt sett kan använda en webbplats.

Die Processhantering PHP-FPM har tre driftslägen: static håller ett fast antal arbetare i beredskap. dynamic anpassar antalet utifrån konfigurationen efter efterfrågan; ondemand startar arbetare vid behov. Det valda driftsläget avgör därmed också när processer är tillgängliga eller startas om.

Fler arbetare ger inte automatiskt mer CPU-tid. De kräver dessutom arbetsminne och kan, vid parallell körning, tillsammans nå ett kontogräns. För att bedöma en delad hosting, CPU Antalet arbetare och resursbudgeten hör därför ihop. Det är inte alla prisplaner som använder PHP-FPM eller tillåter kunderna att själva ändra inställningarna.

CPU-kvot vid parallell belastning

En CPU-kvot fastställer hur mycket beräkningstid en processgrupp får använda inom en viss tidsperiod. I Linux cgroup v2 beskrivs cpu.max denna budget och motsvarande period. Kvoten reserverar alltså inte automatiskt en exklusiv fysisk kärna: den begränsar gruppens totala tillgängliga CPU-tid.

Illustrativt räkneexempel, ingen mätning: En grupp tilldelas 100 millisekunder CPU-tid per 100 millisekunders period. Detta motsvarar i genomsnitt beräkningstiden för en fullt utnyttjad logisk processor. Om två processer beräknar samtidigt på två tillgängliga logiska processorer kan de teoretiskt sett förbruka den gemensamma budgeten efter cirka 50 millisekunder väggtid.

Om budgeten är förbrukad kan processerna strypas fram till nästa period. De båda arbetarna har alltså inte var sin egen budget på 100 millisekunder. Om och när de faktiskt körs parallellt beror bland annat på schemaläggaren, de tillgängliga CPU:erna och deras beteende; exemplet ger ingen konkret svarstid.

För undersökningen använder cgroup v2 i cpu.stat bland annat mätare för Strypning klara. Om de stiger under en representativ belastningsfas är det ett tecken på att kvoten är uttömd. En enskild mätaravläsning ger dock inte någon förklaring till vilken förfrågan som berördes eller om det finns ytterligare flaskhalsar.

Du måste klargöra med leverantören om dessa filer är tillgängliga inom abonnemanget och om de är relevanta för webbplatsen. Delad hosting kan använda andra mekanismer: CloudLinux dokumenterar till exempel egna LVE-gränser för CPU och andra resurser. Utifrån Linux-exemplet går det därför varken att dra slutsatser om den konkreta konfigurationen eller om hur varje hostingkonto fungerar.

CMS, webbutik och bakgrundsjobb

När en CMS-sida inte är cachad utför servern applikationslogik för begäran och hämtar nödvändiga data. Om en stor del av bearbetningen utförs av CPU-arbete, kan en högre prestanda per kärna förkorta denna del. Detta gäller till exempel krävande beräkningar i PHP-koden, men inte automatiskt för hela tiden fram till dess att sidan är färdig.

Om samma förfrågan däremot till största delen består av en databasfråga eller ett externt API, kan PHP-processen under den tiden endast i begränsad utsträckning dra nytta av en snabbare CPU. För beslutet är därför fördelningen av svarstiden på serversidan avgörande: Hur stor del går åt till beräkningar, och hur stor del går åt till att vänta på andra tjänster?

En webbutik visar varför svaret på denna fråga kan variera mellan olika sidor. Offentliga produktsidor kan, under lämpliga förhållanden, sparas som ett färdigt svar. En Cache-träffar kan undvika att PHP-koden bearbetas på nytt i sin helhet; varukorgen och kassan måste däremot ofta ta hänsyn till individuella uppgifter och förblir dynamiska.

Många samtidiga utcheckningsförfrågningar kan därför belasta arbetare eller CPU-budgeten mer än lika många anrop av cachade sidor. Besöksantalet i sig ger inte en fullständig bild av denna belastning: det avgörande är vilka slutpunkter som begärs samtidigt och hur ofta cachen används. I PHP-FPM begränsar dessutom poolinställningen pm.max_children antalet förfrågningar som hanteras samtidigt.

En beräkningskrävande import i backend kan i sin tur dra nytta av snabbare enskilt arbete. Om den körs parallellt med besökarnas förfrågningar kan processerna komma att konkurrera om samma CPU-tidsbudget. Huruvida ett cron-jobb eller en import faktiskt tillhör samma begränsade grupp beror på abonnemanget och dess inställningar; kontakta leverantören innan du fattar ett beslut om kapacitet.

För att kunna göra en meningsfull jämförelse bör du betrakta dessa arbetsbelastningar separat: en typisk dynamisk förfrågan, en fas med flera samtidiga förfrågningar och, i förekommande fall, importen under pågående drift. På så sätt kan du lättare avgöra om hastigheten i ett enskilt arbetssteg eller den tillgängliga totalkapaciteten är den viktigaste faktorn.

Jämföra observationer och flaskhalsar

Ett långsamt svar innebär inte nödvändigtvis att det finns en orsak. Följande översikt kopplar samman typiska iakttagelser med möjligheter som går att testa. Den tar särskilt hänsyn till CPU-tidsgränser, det begränsade antalet arbetare i PHP-FPM och skillnaden mellan lagrad PHP-kod och ett redan genererat svar.

Varje rad i tabellen är en Hypotes, ingen färdig diagnos. Långsamma svar vid parallellkörning kan till exempel bero på att CPU:n stryps, men kan också orsakas av upptagna arbetare eller en databas som väntar. Kontrollera därför om möjligt flera signaler samtidigt och för samma arbetsbelastning, istället för att dra slutsatsen att du behöver byta prisplan utifrån ett enda symptom.

Vid utvärderingen ska du skilja på Svarstid En förfrågan ur genomströmningsperspektiv: Ett snabbare enskilt svar innebär inte automatiskt att fler förfrågningar per sekund kan hanteras vid hög samtidighet. Omvänt kan ett system uppnå god genomströmning och ändå låta enskilda förfrågningar vänta längre.

Den upplevda laddningstiden för en sida är inte heller detsamma som svarstiden på serversidan. Efter svaret kan till exempel ytterligare resurser laddas och bearbetas i webbläsaren. En CPU-uppgradering i webbhotellet påverkar endast den berörda serverns del; för en rättvis jämförelse bör cache-status, den begärda sidan och parallelliteten förbli oförändrade.

När det gäller cachen är det dessutom värt att göra en begreppsmässig åtskillnad: OPcache lagrar kompilerad PHP-kod och kan därmed undvika att koden behöver kompileras på nytt. En sidcache lagrar däremot ett genererat svar. En snabb cacheträff bevisar därför varken att dynamiska förfrågningar har tillräckligt med CPU-resurser eller att OPcache ersätter applikationens logik.

Identifiera begränsningar och väntetider

Börja diagnosen med förfrågningar som är typiska för din webbplats: till exempel en offentlig CMS-sida, en sökning och, om det är en webbutik, kassan. Notera om respektive svar kommer från sidcachen. Jämför därefter enskilda besök och ett antal samtidiga förfrågningar som är representativa för ditt projekt, istället för att enbart titta på det totala antalet besökare.

Separera om möjligt CPU-tid applikationens totala svarstid och väntetiderna för databasen eller externa tjänster. Om CPU-andelen är liten kan en snabbare processor endast förkorta en motsvarande begränsad del av anropet. Om du saknar lämpliga mätvärden, be leverantören om tillgängliga loggar, mätvärden eller en lämplig utvärdering.

Vid parallell belastning ska du kontrollera om tillgängliga arbetare är fullt utnyttjade och om gränsvärdena ökar. Begränsning i PHP-FPM pm.max_children antalet förfrågningar som en pool hanterar samtidigt; om du kan se detta värde eller belastningen beror på abonnemanget. Linux-cgroup-v2-system kan i cpu.stat bland annat visa strömbegränsningsräknare. En stigande räknare är ett skäl att granska CPU-budgeten och mätperioden närmare.

Om SSH och den aktuella filen är tillgängliga, visar cat /proc/self/cgroup den anropande processens cgroup-tillhörighet. Det innebär dock inte att webbförfrågningar körs i samma grupp. Klargör sökvägar, behörigheter och tolkning med leverantören; felkoder kan inte heller generellt kopplas till en viss gräns för varje system med delad hosting.

Kontrollera cacheminnet och jämför priser

Kontrollera först vilka offentliga sidor som säkert kan sparas som ett fullständigt svar. En Sidcache kan undvika upprepad dynamisk bearbetning vid en träff. Personanpassat innehåll, varukorgen och kassan kräver däremot en lämplig cachelagringsstrategi, så att besökarna inte får felaktiga eller föråldrade uppgifter.

Ett annat tillvägagångssätt är att minska arbetsbelastningen vid cache-missar: Undersök långsamma databasfrågor och ta bort onödig dynamisk bearbetning. När det gäller en extern tjänst kan dess svarstid vara avgörande; i så fall bör du först granska detta anrop istället för att utgå från att CPU:n är orsaken. Vilken ändring som hjälper beror på vilken väg som faktiskt är långsam.

Detta ska skiljas från OPcache: Den lagrar kompilerad PHP-kod, men ersätter varken en fullständig sidcache eller körningen av applikationslogiken. Kontrollera tillgängligheten och inställningarna i webbkörningsmiljön. CLI har en egen OPcache-inställning; en titt på kommandoraden i sig visar därför inte konfigurationen för webbförfrågningar.

För att jämföra prestanda bör du jämföra samma förfrågningar med samma programvaruversioner, jämförbara datamängder och dokumenterat cache-tillstånd. Upprepa jämförelsen med samma parallellitetsgrad och ta hänsyn till de tillgängliga resurserna för CPU, arbetare och minne. Annars kan skillnader uppstå på grund av testförhållandena, utan att detta säger något tillförlitligt om processorns prestanda.

Notera dessutom separat hur lång tid enskilda svar tar och hur många förfrågningar som hanteras under en viss tidsperiod. En prisplan kan verka förmånlig för ett enskilt anrop, men ändå nå sina gränser vid samtidig belastning. Värden från en jämförelse gäller inledningsvis endast för den undersökta applikationen och dess förutsättningar.

En snabbare processor eller en större budget?

Om en representativ dynamisk förfrågan huvudsakligen utgör ett CPU-arbete och varken arbetare, minne eller tidsbudget utgör någon begränsning, är högre Prestanda per kärna ett rimligt alternativ för prissättning. Det kan förkorta den beräkningsmässiga delen av den enskilda förfrågan. Hur stor inverkan detta har på det totala svaret beror dock fortfarande på applikationen och dess väntetider.

Om uppgifterna däremot visar på begränsningar eller överbelastade arbetare vid flera samtidiga förfrågningar, bör du överväga en större Resursbudget. Mer CPU-tid kan vara till hjälp om kvotgränsen har nåtts; ytterligare arbetare kräver samtidigt tillräckligt med minne och beräkningstid. Om databasen eller externa tjänster utgör flaskhalsen är en högre CPU-budget i sig inte någon tillförlitlig lösning.

Innan du byter är det värt att jämföra med en optimering av den befintliga installationen. En lämplig sidcache eller en förbättrad sökfunktion kan minska den dynamiska belastningen utan att du omedelbart behöver en större abonnemangsplan. Upprepa diagnosen efter en ändring under jämförbara förhållanden, så att du kan skilja dess effekt från andra faktorer.

En VPS som alternativ till delad hosting ger oftast större inflytande över programvara och konfiguration, men medför också ett större ansvar för säkerhet, uppdateringar och kapacitetsplanering. Virtuella CPU:er är inte exklusiva fysiska kärnor utan uttryckligt löfte från leverantören. Kontrollera därför även där den konkreta resurstilldelningen och avtalsvillkoren.

Innan du fattar ett beslut bör du fråga leverantören om processormodellen, definitionen av CPU-tidsbudgeten och hur man hanterar belastningstoppar. Ta också reda på vilka gränser som gäller för arbetare och lagringsutrymme, om bakgrundsjobb delar samma budget och vilka gränsvärden du kan se. Det är först med dessa uppgifter som du kan sätta den utlovade CPU-prestandan i sitt rätta sammanhang för just ditt abonnemang.