Når det er tid til at vælge en hostingplan, er det vigtigt at vælge en, der bedst matcher kravene på dit WordPress-websted.
For eksempel, vil et ecommerce site, der får 50.000 besøgende pr. måned, typisk være meget mere krævende på ressourcer end en simpel blog med samme mængde trafik.
Dette skyldes simpelthen, at ecommerce sites typisk er dynamiske og kræver flere ressourcer til PHP- og databaseforespørgsler.
Det er her PHP-arbejdere bliver en vigtig spiller. Læs mere nedenfor om, hvad PHP-arbejdere er, og hvordan de bruges til at fremskynde behandlingen af anmodninger på dit websted.
Hvad er en PHP-arbejder?
I forbindelse med WordPress bygger PHP-arbejdere sider, behandler planlagte baggrundsopgaver og mere. Da PHP-arbejdere er direkte ansvarlige for at generere HTML-sider, der kan tjene til dit websteds besøgende, bestemmer de, hvor mange samtidige, ikke-cache-anmodninger, dit websted kan håndtere på et givet tidspunkt.
Lad os sige, at dit WordPress-sted er udstyret med to PHP-arbejdere og ingen opsætning af cache-side. Hvis fire anmodninger kommer til dit websted på nøjagtigt samme tidspunkt, behandles to af disse anmodninger øjeblikkeligt, mens de andre to bliver nødt til at vente i køen, indtil de to første er færdige med at behandle.
Her hos Kinsta bruger vi PHP-arbejdere som en af variablerne til vores forskellige planniveauer. For eksempel har Business 1-planer 4 PHP-arbejdere pr. websted, mens Enterprise-planer starter fra 8 PHP-arbejdere pr. websted.
Selvom vi implementerer cache på serverniveau, for anmodninger, hvor cachen er omgået eller gået glip af, bliver PHP-arbejdere meget vigtige, da de er nødt til at udføre arbejde for hver anmodning.
Vi ser typisk en masse ikke-cachede-anmodninger på websteder med e-handels- og forum-websteder. Derfor kræver disse websteder yderligere PHP-arbejdere for at sikre, at enhver anmodning behandles uden forsinkelser eller timeouts.
Hvis dit websted er meget optimeret eller ikke har en masse PHP-kode (f.eks. et komplekst tema eller en masse WordPress-plugins), skal behandlingen af hver anmodning ske næsten øjeblikkeligt. Selv med 2 PHP-arbejdere og 4 anmodninger ville alle fire anmodninger blive behandlet meget hurtigt.
Kort sagt er en PHP-arbejder en baggrundsproces på en server, der kører PHP-kode.
Hvordan bruger WordPress PHP-arbejdere?
Inden vi finder ud af, hvordan vi optimerer forbruget af PHP-arbejdere i WordPress, skal vi først forstå, hvordan WordPress bruger PHP-arbejdere i første omgang.
En typisk anmodning i et ikke-cachet miljø går sådan ud:
- Webserveren (Nginx eller Apache) modtager en anmodning fra en besøgende.
- Nginx videregiver anmodningen til PHP.
- PHP forespørger MySQL-databasen efter behov og bruger dit temas PHP-skabeloner til at generere en HTML-side.
- PHP overleverer en gengivet HTML-side tilbage til webserveren.
- Siden serveres til den besøgende.
I processen fremhævet ovenfor er trin 3 den mest tids- og ressource-intensive (CPU og RAM). Et meget optimeret websted med minimale databaseforespørgsler og effektiv PHP-kode kommer relativt hurtigt gennem det tredje trin.
Tværtimod, et websted med dårligt skrevet PHP-kode, der giver en masse unødvendige database-spørgsmål, vil bruge meget mere tid på at komme igennem trin 3, hvilket betyder, at anmodninger vil besætte PHP-arbejdere i længere perioder.
Forholdet mellem PHP-arbejdere og CPU
Når det kommer til WordPress-ydeevne, er forholdet mellem PHP-arbejdere og den tilgængelige CPU et vigtigt at overveje.
Hvis manglen på CPU-ressourcer er dit websteds flaskehals, øger antallet af PHP-arbejdere ikke dit websteds ydelse – det vil kun give dit websted mulighed for at behandle flere anmodninger på samme tid med en langsommere ydelse pr. Anmodning.
Lad mig forklare.
Forestil dig en brandhan med en enkelt slange fastgjort til den. Med kun en slange tilsluttet er brandhanen i stand til at give et passende vandtryk. Hvad sker der nu, hvis vi fastgør ti slanger til brandhanen?
Det begrænsede vandtryk er fordelt på ti slanger, hvilket betyder, at hver enkelt slange har mindre vandtryk for at få arbejdet gjort. I denne analogi er brandhanen CPU, og slangerne er PHP-arbejdere.
Med det ovenstående i tankerne, skal du være forsigtig, hvis din vært konstant rådgiver dig om at øge PHP-arbejdere uden at nævne CPU også.
Her på Kinsta er vores brugerdefinerede LXD -containere konfigureret til med rigelige CPU- og RAM -ressourcer. Vi bruger også virtuelle C2- og C3D-maskiner udstyret med Google Clouds hurtigste CPU’er for at hjælpe dit websteds PHP-arbejdere med at køre mere effektivt. Vores skalerbare infrastruktur sikrer, at dit WordPress -websteds PHP -medarbejdere har nok CPU -ressourcer til at fungere med maksimal ydeevne.
Lad os gå tilbage til brandhane-analogien, bare et øjeblik.
Forestil dig, at du er i en situation, hvor du har brug for at slukke ti brande med fem slanger. Når du har tilsluttet alle fem slanger, er du klar over, at vandhanen stadig leverer tilstrækkeligt vandtryk.
I denne situation ville det være fornuftigt at tilslutte et par flere slanger, fordi vandhanens vandtryk ikke er flaskehalsen.
Forestil dig, hvis dit websted klarer sig dårligt, selv med tilstrækkelig CPU og RAM-overhead, er det det, du skal undersøge at øge antallet af PHP-arbejdere som en mulighed for at forbedre ydelsen.
Sådan optimeres dit websteds brug af PHP-arbejdere
Vi har forklaret, at PHP-arbejdere er baggrundsprocesser, der genererer HTML-sider med PHP-kode. Nu er den mest indlysende måde at reducere og optimere PHP-medarbejderanvendelse at reducere mængden af CPU- og PHP-ressourcer, der kræves for at imødekomme anmodninger til dit websted.
Sådan gør du.
1. Konfigurer cache til dit WordPress-sted
Det første trin til at reducere anvendelse af PHP-arbejdere er at konfigurere cache-lag til dit WordPress-sted. Som standard er WordPress et dynamisk CMS, der opfylder alle sideanmodninger, der kræves.
For mange websteder som blogs, online magasiner og porteføljer er det unødvendigt at bruge PHP til dynamisk at generere sider til enhver anmodning.
Sidecache
Det blogindlæg, du læser i øjeblikket, er det perfekte eksempel på en side, der ikke behøver at blive genereret dynamisk. Som mange af vores andre indlæg er indholdet i dette indlæg designet til at være statisk, så der er ikke behov for at bruge CPU-ressourcer til kontinuerligt at generere identiske sider.
I stedet er det bedre at få PHP til at generere siden en gang og derefter cache den. Sidecache har mange åbenlyse fordele i forhold til dynamisk generering af sider med PHP.
Forestil dig for eksempel, hvis et blogindlæg på dit websted bliver viralt og modtager 100.000 sidevisninger inden for få timer efter offentliggørelsen. Uden side-cache ville dine PHP-arbejdere sandsynligvis blive overvældede, og din server ville sandsynligvis gå ned.
Ved cache-side genereres kun visningen på førstesiden dynamisk. De andre 99.999 anmodninger vil blive serveret fra din sidecache, som bruger relativt lidt CPU-ressourcer.
Der er to måder at konfigurere sidecache til dit WordPress-sted.
- Cache-cache på serverniveau med en webserver som Nginx.
- Plugin-baseret sidecache med et WordPress-plugin som WP-Rocket.
For maksimal ydeevne, anbefaler vi at bruge cachelagring på serverniveau, når det er muligt. På Kinsta bruger alle vores websteder Nginx’s FastCGI-cache-modul til superhurtige ydelse.
Hvis din vært ikke tilbyder side-cache-cache-indstilling på serverniveau, er den næste bedste mulighed at bruge et WordPress-cache-plugin til at implementere side-cache på applikationsniveau.
Objekt cache
For WooCommerce-butikker, fællesskabsfora og andre WordPress-websteder, der ikke kan gøre brug af sidecache effektivt, tilføjer en vedvarende objekt cache som Redis foran din MySQL-database kan øge ydeevnen og reducere belastningen på PHP-arbejdere.
Uden en vedvarende objekt cache udføres MySQL-databaseforespørgsler for hver anmodning, selvom resultatet er identisk med en tidligere forespørgsel.
For eksempel vil et community-forum site, der omgår sidecache, oprette separate identiske forespørgsler til databasen for at hente indlægsdata for at oprette en side.
For websteder med stor trafik og databasetunge er denne metode til forespørgsel om databasen ineffektiv, fordi den bruger PHP-medarbejdere til at generere identiske forespørgselsresultater til separate anmodninger. Det er her Redis kommer ind.
Redis gemmer resultaterne af databaseforespørgsler i RAM, hvilket gør det muligt for PHP at få fat i resultaterne af forespørgsler, der allerede er blevet udført. Denne metode til objekt cache giver PHP-arbejdere mulighed for at spare CPU-ressourcer og bruge mindre tid på at opfylde en anmodning, fordi det fjerner behovet for gentagne databaseforespørgsler.
2. Optimer din PHP-kode
Ud over at opsætte caching af sider, er en anden strategi, der vil hjælpe dig med at reducere PHP-arbejdstageranvendelsen, at optimere din PHP-kode. I forbindelse med WordPress kan “optimering af PHP-kode” betyde en række forskellige ting, så lad os se et dybere kig.
En af WordPress ‘mest elskede og mest hadede funktioner (afhængigt af hvem du spørger) er dens udvidelsesmulighed via plugins og kodestykker.
Hvis du vil tilføje en bestand med ticker-widget til dit WordPress-sted, er der et plugin til det. På samme måde, hvis du vil tilføje brugerdefinerede fonte, er der også et features.php-kodestykket til det.
Udvidelse af WordPress-kerne med yderligere funktioner er blevet så let, at vi ofte går over bord uden at tænke over den potentielle indflydelse på webstedsydelsen.
Derfor er den første måde at optimere din PHP-kode at udføre en webstedsdækkende revision for at bestemme, hvilke plugins og kodestykker der virkelig er nødvendige.
Vælg plugins for kvalitet
Oftere end ikke er antallet af plugins på dit WordPress-sted ikke så vigtigt som kvaliteten af plugins. Hvis et plugin ikke er blevet opdateret inden for de sidste seks måneder, vil vi anbefale at vælge et andet, der passer til regningen.
Årsagen til dette er WordPress forbedres konstant. Hvis et plugin ikke er blevet opdateret i årevis, er chancerne for, at dens kode ikke bruger den nyeste WordPress-udvikling og bedste praksis for sikkerhed.
Omvendt, hvis et plugin konstant opdateres med et par ugers mellemrum, er der en god chance for, at udvikleren ser alvorligt på kvalitet, hvilket gør det til et godt valg for dit WordPress-sted.
Brug kun plugins, når det er nødvendigt
Hvis du ønsker at udføre en simpel opgave på dit websted som f.eks. Tilføjelse af JavaScript eller CSS, behøver du ikke altid et plugin til det. I stedet kan du tilføje kode direkte til dit temas PHP-skabeloner eller style.css-fil med et child theme.
Næste gang du er i en situation, hvor du overvejer at installere et plugin, skal du bruge lidt tid på at undersøge, om det først er 100% nødvendigt. Nogle gange er der ingen måde at installere et andet plugin på, og det er okay. Andre gange kan du muligvis undgå at tilføje yderligere kodeudblæsning ved ikke at installere unødvendige plugins.
Vælg lette temaer
Fra vores erfaring med overvågning af tusinder af WordPress-websteder har vi fundet ud af, at temaer lejlighedsvis er årsagen til dårlig PHP-ydelse. For at imødekomme WordPresss alsidighed som et generel CMS-kode koder nogle udviklere temaer for at arbejde i en række forskellige anvendelsessager.
Ofte resulterer dette i kodetunge og oppustede temaer, der ikke bruger PHP- og databaseforespørgsler på en effektiv måde.
Når du bygger et WordPress-websted, er det vigtigt at vælge et tema, der er mest performant og tilpasses – GeneratePress, OceanWP og Astra er tre eksempler.
3. Vælg en præstationsfokuseret WordPress-vært
Ve det eller ej, at vælge den rigtige WordPress-host kan have en enorm indflydelse på dit websteds ydelse. Da en PHP-arbejders effektivitet er direkte korreleret med CPU og RAM, kan hosting af dit websted på en moderne server med den nyeste hardware hjælpe dig med at optimere anvendelse af PHP-arbejdere.
Her er to eksempler, der viser, hvorfor det er vigtigt at vælge en ydelsesfokuseret host for dine WordPress-websteder.
Højtydende CPU’er
PHP bruger CPU-ressourcer til at udføre kode. En hurtigere CPU betyder hurtigere kodeudførelse. Hos Kinsta bruger vi Google Clouds hurtigste servere – compute optimized C2 og compute engine general-purpose C3D VM’er.
Disse VM’er er udstyret med de nyeste Intel Xeon-processorer, der er i stand til at arbejde ved 3,8 GHz all-core turbo. I vores benchmark-test så vi C2-maskiner, der overgik traditionelle N1-maskiner med 2-4x, mens C3D-maskiner oplevede, at responstider blev forbedret med yderligere 20% til 50% .
Hurtig SSD-opbevaring
Disk I / O-hastighed kan have en direkte indflydelse på kodeudførelse og databaseforespørgsler. Hvis din database er gemt på en langsom mekanisk disk eller en skybaseret SSD uden tilstrækkelig IOPS (input / output operationer pr. Sekund), bliver dine PHP-arbejdere tvunget til at bruge mere tid på at imødekomme en anmodning.
Vi bruger Google Cloud Platforms højtydende SSD-lager for at sikre, at dit WordPress-sted har adgang til hurtig disk I / O.
4. Arbejde med en performanceekspert (valgfrit)
Hvis du er usikker på, hvordan du løser et præstationsproblem på dit websted, anbefaler vi, at du samarbejder med en kvalificeret ydelsesekspert for at diagnosticere problemet.
En ekspert kan hjælpe dig med at identificere specifikke flaskehalse i din kode ved at bruge avancerede overvågningsværktøjer som New Relic eller Query Monitor WordPress-plugin.
Ved at zoome ind og inspicere individuelle PHP-processer og databaseforespørgsler er det muligt at identificere specifikke blokke med kode og deres tilknyttede funktioner, der lægger stor belastning på dit websteds PHP-arbejdere.
For at opsummere optimering af PHP-medarbejder skal du huske følgende tip.
- CPU og RAM skal skaleres sammen med PHP-arbejdere. Hvis CPU-brug er låst til 100%, vil tilføjelse af flere PHP-arbejdere ikke forbedre ydelsen.
- Hosting af dit websted med en host der er fokuseret på præstation kan løse mange ydelsesproblemer.
- Sidecache og objekt cache kan reducere belastningenen på PHP-arbejdere markant.
- Brug af WordPress-plugins og -temaer af høj kvalitet kan reducere mængden af unødvendig kodeopblæsning på dit websted.
- Arbejd om nødvendigt med en præstationsekspert for at identificere og løse komplekse problemer.
Resultater af ikke at have nok PHP-arbejdere
For at opnå hurtig og pålidelig ydelse til dit WordPress-websted er det vigtigt at sikre, at det har nok PHP-arbejdere. Når PHP-arbejdere allerede er travlt på et sted, begynder de at opbygge en kø.
Når du har nået din grænse for PHP-medarbejdere, begynder køen at skubbe ældre anmodninger ud, hvilket kan resultere i 504 error eller ufuldstændige anmodninger.
En anden almindelig fejl, vi ser på grund af manglen på PHP-arbejdere, er 502 dårlige gatewayfejl. Disse adskiller sig lidt fra 504 fejl, fordi fejlen opstår efter en timeout på 60 sekunder i PHP-arbejdernes kø.
Disse fejl giver ikke kun en dårlig brugeroplevelse for dine besøgende, men de kan også have en negativ indflydelse på dit websteds SEO.
Der er en række forskellige faktorer, der kan forårsage langsom sidebelastning eller fejl. For eksempel, hvis en ikke-gemt anmodning kræver en masse data fra databasen, kan det resulterende forespørgsel tage 20-30 sekunder at gennemføre.
I denne situation ville en PHP-arbejder være besat i mindst et halvt minut. Hvis dit websted kun har to PHP-arbejdere, kan bare to eller tre af disse lange anmodninger være nok til at begynde at forårsage fejl.
For at løse dette kan optimering af MySQL-databasen og forøgelse af PHP-medarbejdere, hvis CPU allerede er maksimeret, forbedre ydelsen.
Estimering af antallet af nødvendige PHP-arbejdere
Hver af hostingplanerne på Kinsta inkluderer et vist antal PHP-arbejdere. Det inkluderede antal PHP-medarbejdere er baseret på historiske ressource-forbrugsmålinger, vi har samlet i de sidste par år. Generelt kræver websteder med primært statisk indhold- artikler, statiske sider og porteføljer – mange PHP-arbejdere.
For større WordPress-websteder med mere dynamisk funktionalitet som e-handel eller diskussionsfora, fandt 4 PHP-arbejdere et godt udgangspunkt. Dette kan dog variere efter sted, da hver vil have sit eget unikke sæt af temaer, plugins, databaseforespørgsler og cache-til-cache-forhold.
I nogle tilfælde kan flere PHP-darbejdere være nødvendige for hurtig og pålidelig ydelse. Hvis du er usikker på, hvor mange PHP-medarbejdere dit websted har brug for på Kinsta, kan vores salgs- og supportteam hjælpe dig med at finde ud af det.
PHP-arbejder grænsekort
PHP-arbejdstagerens grænseskema i MyKinsta-analytics giver dig mulighed for at se, hvor mange gange PHP-motoren rapporterede, at den nåede det maksimale tildelte arbejdstagernummer i sin fejllog. Dette diagram kan hjælpe dig med at måle, om præstationsoptimeringer har indflydelse på din PHP-arbejders brug.
For eksempel, hvis du skiftede dit websteds PHP-version fra 5.6 til 7.4, vil du sandsynligvis se et fald i PHP-arbejder grænserne, fordi PHP 7.4 er meget hurtigere end 5.6.
På samme måde, hvis du arbejder med en præstationsekspert til at rette lange databaseforespørgsler og skifte til et mere letvægtigt tema, kan du bruge PHP-arbejder grænseskema til at se forskellene før og efter optimeringerne.
Cache analyse diagram
Du kan også bruge cache-analyserapporten i MyKinsta til at bestemme antallet af cache-hits, bypasses, misses og udløb. Disse data kan være især nyttige, når du optimerer dit websteds brug af PHP-arbejdere.
Cache bypass med query strings
Som standard omgår URL’er med query strings som https://kinstalife.com/?query=123 sidecachen. I nogle tilfælde kan forespørgselsstrengene resultere i en stor stigning i unødvendig PHP- og CPU-brug.
Hvis du f.eks. besøger et link fra Facebook, vil du ofte se ?fbclid= query string i slutningen af webadressen. Tilsvarende kan du muligvis se UTM-sporingsparametre, når du har klikket på et link i et e-mail-nyhedsbrev.
Hvis et indlæg på dit websted bliver viralt og konstant fås adgang til det med en query string, vil du være i stand til at identificere den specifikke URL med cache-analyserapporten.
Med det centrale stykke information kan du derefter kontakte vores supportteam for at tvinge cache til den specifikke URL for at reducere belastningen på dine PHP-arbejdere.
Identificering af ressource-tunge plugins
I nogle tilfælde kan cache-analysekortet også bruges til at identificere ressourcetunge plugins og processer.
Hvis du f.eks. Ser, at den øverste cache-bypass-URL peger på en fil i et specifikt plugins bibliotek, er der en god chance for, at plugin er ansvarlig for højt forbrug af PHP-arbejder.
Hvis du ser en masse plugin-relaterede anmodninger på din cache-bypass-liste, kan du samarbejde med en udvikler om at løse problemet eller skifte til et plugin, der bruger færre ressourcer.
Resumé
Målet med at opretholde et hurtigt WordPress-sted er at maksimere effektiviteten af backend. Når PHP-arbejdere udnyttes korrekt ved at finde en balance mellem arbejdstæller, CPU-brug og kodeoptimering, kan WordPress være et ekstremt performant CMS.
Hvis du har spørgsmål til, hvor mange PHP-arbejdere du muligvis har brug for, eller du tror, at du muligvis ser fejl på grund af manglen på PHP-arbejdere, skal du åbne en billet med vores supportteam for at få hjælp.
Nu er din tur: Hvilke optimeringsstrategier bruger du for at holde dit WordPress-site kørende? Fortæl os det i kommentarerne!
Brian har været WordPress-bruger i over 10 år og nyder at dele sin viden med fællesskabet. I sin fritid nyder Brian at spille klaver og udforske Tokyo med sit kamera. Få kontakt med Brian på hans hjemmeside på brianli.com.
Skriv et svar