När det är dags att välja en hosting plan, är det viktigt att välja en som bäst matchar kraven för din WordPress-webbplats.

En e-handel webbplats som får 50.000 besökare per månad kommer till exempel vanligtvis att kräva mycket mer resurser än en enkel blogg med samma mängd trafik.

Detta beror helt enkelt på det faktum att webbplatser för e-handel vanligtvis är dynamiska, och kräver mer resurser för PHP och databasfrågor.

Det är där PHP-bearbetare blir viktiga. Läs mer nedan om vad PHP-bearbetare är och hur de används för att påskynda behandlingen av förfrågningar på din webbplats.

Vad är en PHP-bearbetare?

När det gäller WordPress, bygger PHP-bearbetare sidor, bearbetar schemalagda bakgrundsuppgifter och mycket mer. Eftersom PHP-bearbetare är direkt ansvariga för att generera HTML-sidor till din webbplats besökare, avgör de hur många samtidiga okopplade förfrågningar som din webbplats kan hantera vid varje given tidpunkt.

Låt oss till exempel säga att din WordPress-webbplats är utrustad med två PHP-bearbetare och ingen setup för sido-cachelagring. Om fyra begäranden kommer till din webbplats vid exakt samma tidpunkt, kommer två av dessa begäranden att behandlas omedelbart, medan de andra två måste vänta i kön tills de två första har bearbetats klart.

Här på Kinsta använder vi PHP-bearbetare som en av variablerna för våra olika plannivåer. Business 1-planer har exempelvis 4 PHP-bearbetare per webbplats, medan Enterprise-planer börjar från 8 PHP-bearbetare per webbplats.

Även om vi implementerar cachelagring på servernivå, för begäranden där cachen kringgås eller missas, är PHP-bearbetare mycket viktiga eftersom de måste arbeta för varje begäran.

Vanligtvis ser vi en hel del icke-cachelagrade förfrågningar på webbplatser för e-handel och community forum. Därför kommer dessa platser att kräva ytterligare PHP-bearbetare för att säkerställa att varje begäran behandlas utan förseningar eller timeout.

Om din webbplats är mycket optimerad eller saknar en hel del PHP-kod (t.ex. inte har ett komplext tema eller så många WordPress-plugins), bör bearbetningen av varje begäran ske nästan omedelbart. Även med 2 PHP-bearbetare och 4 förfrågningar, skulle alla fyra förfrågningarna hanteras mycket snabbt.

Enkelt uttryckt är en PHP-arbetare en bakgrundsprocess på en server som kör PHP-kod.

Hur använder WordPress PHP-arbetare?

Innan vi kommer in på hur man optimerar PHP-bearbetare för WordPress, måste vi först förstå hur WordPress använder PHP-bearbetare.

En typisk begäran i en okopplad miljö går till ungefär så här:

  1. Webbservern (Nginx eller Apache) får en begäran från en besökare.
  2. Nginx skickar begäran till PHP.
  3. PHP frågar MySQL-databasen efter behov och använder temats PHP-mallar för att generera en HTML-sida.
  4. PHP skickar en renderad HTML-sida tillbaka till webbservern.
  5. Sidan visas för besökaren.

I den process som visas ovan är steg 3 mest tids- och resurskrävande (CPU och RAM). En mycket optimerad plats med minimala databasfrågor och en effektiv PHP-kod kommer att ta sig igenom det tredje steget relativt snabbt.

En webbplats med dåligt skriven PHP-kod som gör en hel del onödiga databasfrågor kommer istället att spendera mycket tid på att ta sig igenom steg 3, vilket innebär att förfrågningar kommer att ockupera PHP-bearbetare under längre tidsperioder.

Förhållandet mellan PHP Arbetare och CPU

När det gäller WordPress prestanda, är förhållandet mellan PHP-bearbetare och tillgänglig CPU viktigt att tänka på.

Om bristen på CPU-resurser är din webbplats flaskhals, kommer fler PHP-bearbetare inte att öka din webbplats prestanda – det kommer bara att tillåta din webbplats att bearbeta fler förfrågningar samtidigt med långsammare prestanda per begäran.

Låt mig förklara.

Föreställ dig en brandpost med en enda slang. Med endast en slang ansluten kan brandposten skapa ett tillräckligt stort vattentryck. Vad händer om vi fäster tio slangar på brandposten?

Det begränsade vattentrycket sprids över tio slangar, vilket innebär att varje enskild slang har mindre vattentryck. I denna analogi är brandposten processorn, och slangarna är PHP-bearbetare.

Med ovanstående i åtanke bör du vara försiktig om din host ständigt råder dig att skaffa fler PHP-bearbetare utan att nämna CPU.

Här på Kinsta är våra anpassade LXD-containers konfigurerade för att ha gott om CPU- och RAM-resurser. Vi använder dessutom virtuella C2- och C3D-maskiner som är utrustade med Google Clouds snabbaste CPU:er. Allt för att hjälpa din webbplats PHP-bearbetare att fungera mer effektivt. Dessa hjälper PHP-bearbetarna på din webbplats att fungera mer effektivt. Vår skalbar infrastruktur säkerställer att PHP-bearbetarna på din WordPress-webbplats har tillräckligt med CPU-resurser för att fungera med högsta möjliga prestanda.

Låt oss gå tillbaka till brandpost-liknelsen ett ögonblick.

Föreställ dig att du är i en situation där du måste släcka tio bränder med fem slangar. Efter att ha anslutit alla fem slangarna, inser du att brandposten fortfarande ger tillräckligt vattentryck.

I denna situation skulle det vara meningsfullt att ansluta några fler slangar eftersom brandpostens vattentryck inte är flaskhalsen.

Fungerar din webbplats dåligt även med tillräcklig CPU och RAM? Då bör du fundera på att öka antalet PHP-bearbetare som ett alternativ till att förbättra webbplatsens prestanda.

Hur man optimerar webbplatsens användning av PHP-bearbetare

Vi har förklarat att PHP-arbetare är bakgrundsprocesser som genererar HTML-sidor med PHP-kod. Det mest uppenbara sättet att minska och optimera användningen av PHP-bearbetare är att minska de CPU och PHP-resurser som krävs för att uppfylla förfrågningar till din webbplats.

Så här gör du.

1. Ställ in cachelagring för din WordPress-webbplats

Det första steget för att optimera PHP-bearbetarna är att inrätta lager av cachelagring för din WordPress-webbplats. Som standard är WordPress ett dynamiskt CMS som uppfyller varje sidas begäran när man begär det.

För många webbplatser som exempelvis bloggar, nättidningar och portfolios, är det onödigt att använda PHP för att dynamiskt generera sidor för varje begäran.

Cachelagring av sidor

Blogginlägget du läser för närvarande är det perfekta exemplet på en sida som inte behöver genereras dynamiskt. Precis som många av våra andra inlägg är innehållet i det här inlägget utformat för att vara statiskt, så det finns ingen anledning att spendera CPU-resurser för att generera identiska sidor kontinuerligt.

Det är istället bättre att låta PHP generera sidan en gång och sedan cachelagra den. Sid-cachelagring har många uppenbara fördelar jämfört med dynamiskt genererande av sidor med PHP.

Förställ dig till exempel att ett blogginlägg på din webbplats blir viralt och får 100 000 sidvisningar inom några timmar efter publiceringen. Utan sid-cachelagring, skulle dina PHP-bearbetare sannolikt bli överansträngda och din server skulle sannolikt krascha.

Med sidcachelagring genereras endast den första sidans vy dynamiskt. De andra 99.999 förfrågningar skulle skickas från din sid-cachelagring, som använder relativt lite CPU-resurser.

Det finns två sätt att ställa in sid-cachelagring för din WordPress-webbplats.

  1. Cachelagring på servernivå med en webbserver som Nginx.
  2. Plugin-baserad sid-cachelagring med ett WordPress-plugin som WP-Rocket.

För maximal prestanda rekommenderar vi att du använder cachelagring på servernivå när det är möjligt. Alla Kinsta´s webbplatser använder Nginx FastCGI-cachemodul för supersnabb prestanda.

Om din host inte erbjuder alternativet för sid-cachelagring på server-nivå, är det näst bästa alternativet att använda ett WordPress cachelagrings-plugin för att ställa in cachelagring på applikations-nivå.

Cachelagring av objekt

Det finns WooCommerce-butiker, community-forum och andra WordPress-webbplatser som inte kan använda sig av sid-cachelagring effektivt. De kan lägga till en beständig objekt-cachelagring som Redis framför sin MySQL-databas för att öka prestandan och minska belastningen på PHP-bearbetarna.

Utan en beständig objektcache körs MySQL-databasfrågor för varje begäran även om resultatet är identiskt med en tidigare fråga.

En webbplats för community-forum som kringgår sid-cachelagringen kommer till exempel att skicka separata identiska frågor till databasen för att hämta inläggsdata för att skapa en sida.

För högtrafikerade och databastunga platser är metoden att fråga databasen ineffektiv eftersom den använder PHP-bearbetare för att generera identiska frågeresultat för separata begäranden. Det är där Redis gör nytta.

Redis lagrar resultaten av databasfrågorna i RAM, vilket gör att PHP kan få svaren på frågor som redan har ställts. Denna metod för objekt-cachelagring gör att PHP-bearbetarna kan spara CPU-resurser och spendera mindre tid med att svara på en begäran eftersom det tar bort behovet av repetitiva databasfrågor.

2. Optimera din PHP-kod

Förutom att ställa in sid-cachelagring, kan du optimera din PHP-kod för att minska användningen av PHP-bearbetare. När det gäller WordPress, kan ”optimera PHP-kod” betyda en mängd olika saker, så låt oss ta en djupare titt.

En av WordPress mest älskade och mest hatade funktioner (beroende på vem du frågar) är dess utökningsbarhet via plugins och kodavsnitt.

Om du vill lägga till en stock ticker-widget till din WordPress-webbplats, finns det ett plugin för detta. Om du vill lägga till anpassade teckensnitt, finns det ett kodavsnitt i functions.php även för detta.

Att utöka WordPress kärna med ytterligare funktioner har blivit så enkelt att vi ofta gör det utan att tänka på den potentiella effekten på webbplatsens prestanda.

Därför är det första sättet att optimera din PHP-kod att utföra en webbplatsomfattande revision för att avgöra vilka plugins och kodavsnitt som verkligen är nödvändiga.

Välj kvalitet-plugins

Väldigt ofta, är antalet plugins på din WordPress-webbplats inte lika viktigt som kvaliteten på de plugins du har. Om ett plugin inte har uppdaterats under de senaste sex månaderna rekommenderar vi att du väljer ett annat som passar.

Anledningen till detta är att WordPress ständigt förbättras. Om ett plugin inte har uppdaterats i år, finns risken att dess kod inte använder den senaste praxisen när det gäller WordPress utveckling och säkerhet

Om ett plugin istället uppdateras hela tiden med några veckors mellanrum, finns  finns en god chans att utvecklaren menar allvar med kvaliteten, vilket gör det till ett bra val för din WordPress-webbplats.

Använd endast plugins när det behövs

Om du vill utföra en enkel uppgift på din webbplats som att lägga till JavaScript eller CSS, behöver du inte alltid ett plugin för detta. Istället kan du lägga till kod direkt till dina tema-mallar för PHP eller style.css-fil med ett barn-tema.

Nästa gång du är i en situation där du funderar på att installera ett plugin, undersök först om det är 100% nödvändigt. Ibland är den enda lösningen att installera ett plugin. Andra gånger kanske du kan undvika att lägga till ytterligare kod genom att inte installera onödiga plugins.

Välj lätta teman

Efter att ha övervakat tusentals WordPress-webbplatser, har vi funnit att teman ibland är orsaken till dålig PHP-prestanda. För att tillgodose WordPress mångsidighet som ett general purpose CMS, skapar vissa utvecklare teman som ska fungera för en mängd olika områden.

Ofta resulterar detta i kodtunga och uppsvällda teman som inte använder PHP och databasfrågor på ett effektivt sätt.

När du bygger en WordPress-webbplats, är det viktigt att välja ett tema som är mest högpresterande och anpassningsbart – GeneratePress, OceanWP och Astra är tre exempel.

3. Välj en prestandafokuserad WordPress-host

Tro det eller ej, men att välja rätt WordPress-host kan ha en enorm inverkan på resultatet på din webbplats. Eftersom en PHP-bearbetares effektivitet är direkt korrelerad med CPU och RAM, kan hostning av din webbplats på en modern server med den senaste hårdvaran hjälpa dig att optimera användningen av PHP-bearbetare.

Här är två exempel som visar varför det är viktigt för dina WordPress-webbplatser att välja en prestandafokuserad host.

Högpresterande processorer

PHP använder CPU-resurser för att köra kod. En snabbare CPU innebär snabbare kodkörning. På Kinsta använder vi Google Clouds snabbaste servrar – beräkningsoptimerade C2 och beräkningsmotorns allmänna C3D VMs.

De här virtuella datorerna är utrustade med de senaste Intel Xeon-processorerna som kan fungera med 3,8 GHz turbo med alla kärnor. I våra riktmärkes-tester såg vi att C2-maskiner överträffade traditionella N1-maskiner med 2-4 gånger, medan C3D-maskiner fick svarstider som förbättrades med ytterligare 20 % till 50 %.

Snabb SSD-lagring

Disk-I/O-hastighet kan ha en direkt inverkan på kodkörning och databasfrågor. Om databasen lagras på en långsam mekanisk disk eller en molnbaserad SSD utan tillräcklig IOPS (input/utdataoperationer per sekund) kommer dina PHP-bearbetare att tvingas ägna mer tid åt att uppfylla en begäran.

Vi använder Google Cloud plattformens högpresterande SSD-lagring för att säkerställa att din WordPress-webbplats har tillgång till snabb disk-I/O.

4. Arbeta med en prestandaexpert (valfritt)

Om du är osäker på hur du hanterar ett prestandaproblem på din webbplats rekommenderar vi att du arbetar med en kvalificerad prestandaexpert för att diagnostisera problemet.

En expert kan hjälpa dig att identifiera specifika flaskhalsar i din kod med hjälp av avancerade övervakningsverktyg som New Relic eller WordPress-pluginet Query Monitor.

Genom att zooma in och inspektera enskilda PHP-processer och databasfrågor, är det möjligt att identifiera specifika block av kod och deras tillhörande funktioner som lägger en hög belastning på din webbplats PHP-bearbetare.

För att sammanfatta optimeringen av PHP-bearbetare, ha följande tips i åtanke.

  1. CPU och RAM bör skalas upp tillsammans med php-bearbetare. Om CPU-användningen är låst på 100%, kommer fler PHP-bearbetare inte att förbättra prestandan.
  2. Att hosta din webbplats hos en prestandafokuserad host kan lösa många prestandaproblem.
  3. Sid-cachelagring och objektcache kan minska belastningen på PHP-bearbetarna avsevärt.
  4. Att använda förstklassiga WordPress-plugins och teman kan minska mängden onödig kod på din webbplats.
  5. Om det behövs arbeta med en prestandaexpert för att identifiera och lösa komplexa problem.

Resultatet av att inte ha tillräckligt många PHP-bearbetare

För att uppnå en snabb och tillförlitlig prestanda för din WordPress-webbplats är det viktigt att se till att den har tillräckligt många PHP-bearbetare. När PHP-bearbetarna redan är upptagna på en webbplats börjar de bilda en kö.

När du har nått din gräns för PHP-bearbetare börjar kön att skicka ut äldre begäranden som kan resultera i 504-felet  eller ofullständiga begäranden.

Ett annat vanligt fel som uppstår pga av bristen på PHP-bearbetare är 502 bad gateway-felet. Detta skiljer sig något från 504-felet eftersom felet uppstår efter en timeout på 60 sekunder i PHP-bearbetarnas kö.

Dessa fel skapar inte bara en dålig användarupplevelse för dina besökare, de kan även ha en negativ inverkan på din webbplats SEO.

502-felet (Bad Gateway).
502-felet (Bad Gateway).

Det finns ett antal olika faktorer som kan orsaka långsamma sid-laddningar eller fel. Om exempelvis en okopplad begäran kräver mycket data från databasen kan den resulterande frågan ta 20-30 sekunder att slutföra.

I denna situation skulle en PHP-bearbetare vara upptagen i minst en halv minut. Om din webbplats bara har två PHP-bearbetare, kan endast två eller tre av dessa långa förfrågningar vara tillräckligt för att börja orsaka fel.

För att lösa detta, kan optimering av MySQL-databasen och ökning av antal PHP-bearbetare förbättra prestandan. Detta gäller om inte CPU redan är maxad.

Beräkna antalet nödvändiga PHP-bearbetare

Var och en av host-planerna på Kinsta innehåller ett visst antal PHP-bearbetare. Det inkluderade antalet PHP-bearbetare baseras på de analyser av resursanvändning som vi har samlat in under de senaste åren. I allmänhet kräver webbplatser med främst statiskt innehåll – artiklar, statiska sidor och portfolios – inte många PHP-bearbetare.

För större WordPress-webbplatser med mer dynamisk funktionalitet som e-handel eller diskussionsforum, har vi kommit fram till att 4 PHP-bearbetare kan vara en bra utgångspunkt. Detta kan dock variera per webbplats eftersom var och en kommer att ha sin egen unika uppsättning av teman, plugins, databasfrågor och olika saker som är cachelagrade och icke-cachelagrade.

I vissa fall kan fler PHP-bearbetare behövas för en snabb och tillförlitlig prestanda. Om du är osäker på hur många PHP-bearbetare din webbplats behöver på Kinsta, kan våra sälj- och supportteam hjälpa dig att ta reda på det.

PHP-bearbetare Gräns Diagram

Diagrammet för PHP-bearbetargränser i MyKinsta analytics låter dig se hur många gånger PHP-motorn rapporterat att den nått det maximala tilldelade bearbetarnumret i felloggen. Det här diagrammet kan hjälpa dig att bedöma om prestandaoptimeringar påverkar dina PHP-bearbetare.

Övre cache förbikopplingar.
Övre cache förbikopplingar.

Om du exempelvis bytte din webbplats PHP-version från 5,6 till 7,4, skulle du förmodligen se en nedgång i gränsen för PHP-bearbetare eftersom PHP 7.4 är mycket snabbare än 5,6.

Om du arbetat med en prestandaexpert för att åtgärda långa databasfrågor och växla till ett mer lätt tema, kan du använda diagrammet för PHP-bearbetargränsen för att se skillnaderna före och efter optimeringarna.

Diagram över cachelagrings-analys

Du kan även använda rapporten för cachelagringsanalysen i MyKinsta för att fastställa antalet cachelagrings-träffar, förbikopplingar, missar och förfallodatum. Dessa data kan vara särskilt användbara när du optimerar webbplatsens användning av PHP-bearbetare.

Förbikopplingar av cachelagring med frågesträngar

Som standard kringgår webbadresser med frågesträngar som https://kinstalife.com/?query=123 sid-cachelagringen. I vissa fall kan frågesträngar resultera i väldigt mycket onödig PHP- och CPU-användning.

Om du exempelvis besöker en länk från Facebook visas ofta frågesträngen ?fbclid= i slutet av webbadressen. På samma sätt kan du se UTM spårnings-parametrar efter att ha klickat på en länk i ett  nyhetsbrev.

En URL med en frågesträng (?querystring=123).
En URL med en frågesträng (?querystring=123).

Om ett inlägg på din webbplats blir viralt och ständigt nås med en frågesträng kan du identifiera den specifika webbadressen med rapporten för cachelagrings-analys.

Med denna viktiga information, kan du sedan kontakta vårt supportteam för att tvinga på en specifik webbadress cachelagring för att minska belastningen på dina PHP-bearbetare.

Identifiera resurstunga plugins

I vissa fall kan cacheanalysdiagrammet även användas för att identifiera resurstunga plugins och processer.

Om du exempelvis ser att en viss fil i en viss plugin-katalog inte cachelagras och kräver mycket prestanda, finns det en god chans att detta plugin är ansvarigt för överansträngning av dina PHP-bearbetare.

Om du ser många plugin-relaterade begäranden i listan över förbikoppling av cachelagringen kan du arbeta med en utvecklare för att lösa problemet eller byta till ett plugin-program som använder färre resurser.

Sammanfattning

Målet med att upprätthålla en snabb WordPress-webbplats är att maximera effektiviteten i backend. När PHP-bearbetare utnyttjas på rätt sätt och hittar en balans mellan bearbetning, CPU-användning och kodoptimering, kan WordPress vara en extremt högpresterande CMS.

Om du har några frågor om hur många PHP-bearbetare du kan behöva, eller om du tror att fel uppstår på grund av bristen på PHP-bearbetare, vänligen hör av dig till vårt supportteam för hjälp. 

Nu är det din tur: Vilka optimeringsstrategier använder du för att få din WordPress-webbplats att fungera smidigt? Låt oss få veta i kommentarerna!

Brian Li

Brian har varit WordPress-användare i över 10 år och tycker om att dela sin kunskap med communityn. På fritiden tycker Brian om att spela piano och utforska Tokyo med sin kamera. Ta kontakt med Brian på hans hemsida på brianli.com.