Ga naar de inhoud 
php-medewerkers zijn onafhankelijke processen die PHP-code uitvoeren en zo elk dynamisch verzoek van een website verwerken. Als er te veel niet-gecachette aanvragen tegelijkertijd de server bereiken, nemen de bestaande workers alle slots in beslag, ontstaat er een wachtrij en leidt de bottleneck tot lange responstijden, TTFB-tips en fouten.
Centrale punten
Ik vat de volgende kernboodschappen compact samen, zodat je snel de juiste beslissingen kunt nemen voor Prestaties en capaciteit.
- Definitie vanPHP Workers verwerken verzoeken serieel, slechts één verzoek per worker.
- KnelpuntTe weinig werkers creëren wachtrijen, TTFB neemt toe en time-outs dreigen.
- BronnenWorkers hebben CPU-kernen nodig; een onjuiste verhouding veroorzaakt contextwisseling.
- CachingHoe meer hits uit de cache, hoe minder werkers belast worden tijdens verkeerspieken.
- SchalenPas het aantal werknemers aan het paginaprofiel, de plug-ins en interacties aan.
Wat zijn PHP Workers in de hostingcontext?
Ik begrijp het PHP-medewerkers als digitale wachters die elk dynamisch verzoek afzonderlijk bedienen. Een worker leest het PHP script, triggert database queries en gebruikt deze om de HTML voor de browser te bouwen. Als er een taak loopt, blijft de worker gebonden totdat deze is voltooid en is dan pas weer beschikbaar, parallel werkt het niet. In WordPress voeren workers ook terugkerende taken uit, zoals cronjobs, het verzenden van e-mails en beveiligingscontroles. Dit is precies waarom het aantal en de kwaliteit van de werkers de waargenomen snelheid van een website beïnvloeden. website massief.
Wanneer en waarom doet het knelpunt zich voor?
Er ontstaat een knelpunt zodra er meer ongecacheerde verzoeken tegelijk binnenkomen dan Werknemer beschikbaar zijn. Elk extra verzoek komt dan in een wachtrij terecht en wacht op een vrij slot. Dit verlengt de tijd tot de eerste byte, verlengt de laadtijd en kan ertoe leiden dat afrekenprocessen worden geannuleerd. In winkels of ledenruimten verergert gepersonaliseerde inhoud de situatie omdat de cache niet in staat is om veel antwoorden te geven, wat het afrekenproces kan vertragen. Belasting direct naar de workers. In deze situatie bereik ik het grootste effect met verstandige caching, geoptimaliseerde plugins en een harmonieuze worker-to-CPU-verhouding.
Symptomen herkennen: Metriek en logs correct lezen
Ik kijk eerst naar TTFBomdat stijgende waarden op wachtrijen duiden. Fouten zoals 504 Gateway Timeout treden op wanneer verzoeken te lang geblokkeerd blijven en hard worden afgebroken. In het hostingpaneel herken ik wachtrijen via hoge procesaantallen met tegelijkertijd een laag netwerkgebruik, wat typisch is voor geblokkeerde verzoeken. Werknemer is. Toegangslogs tonen dan veel gelijktijdige aanvragen naar niet-gecacheerde paden zoals het winkelmandje, de kassa of persoonlijke dashboards. Als de responstijden in de backend tegelijkertijd toenemen, blokkeren zware beheeracties afzonderlijke werkers meestal langer dan noodzakelijk.
Belangrijk onderscheid: webserver vs. PHP-FPM
Ik maak een duidelijk onderscheid tussen web server workers (bijv. NGINX/Apache) en PHP-FPM-medewerkers. Dankzij Keep-Alive en HTTP/2 kan de webserver veel verbindingen multiplexen en statische activa extreem parallel serveren. De echte bottleneck ontstaat echter in PHP-FPM, waar elk kindproces precies één verzoek verwerkt. Zelfs als de browser tientallen verzoeken parallel opent, beperkt het aantal PHP-processen de gelijktijdige verwerking van dynamische paden. Dit onderscheid verklaart waarom pagina's met veel statische bestanden snel verschijnen, terwijl individuele, dynamische eindpunten (afrekenen, inloggen, REST API) nog steeds vastlopen.
Optimaal aantal werkers: rekenkernen, RAM en app-profiel
Het zinvolle aantal werkers hangt af van het aandeel dynamische pagina's, het plugin-landschap en de beschikbare CPU-kernen uit. Ik plan nooit voor aanzienlijk meer workers dan CPU cores, omdat permanente contextwisseling de latentie verhoogt. Twee tot vier workers zijn meestal voldoende voor kleine blogs, terwijl actieve shops en LMS'en aanzienlijk meer nodig hebben. De doorslaggevende factor blijft de interactie: meer workers zonder CPU-reserves leveren geen voordelen op. Versnelling. Daarom test ik met belasting, meet TTFB en kijk of de keu verdwijnt voordat ik verder upgrade.
| Scenario | Niet in de cache opgeslagen | Werknemer | CPU-kernen | Effect | Actie |
|---|---|---|---|---|---|
| Blog met cache | Zeer laag | 2-4 | 2-4 | Snelle levering | Cache onderhouden, Plugins slank blijven |
| WooCommerce met tips | Middelhoog | 6-12 | 4-8 | Korte wachttijden | Kassa verlichten, Werknemer verhogen |
| Leden/LMS | Hoog | 8-16 | 8-16 | Minder time-outs | Cache personalisatie, CPU vastdraaien |
| API-intensieve app | Hoog | 8-20 | 8-20 | Meer zelfs TTFB | Query's optimaliseren, Grenzen stel in |
Vuistregels voor dimensionering
Voor een eerste gevoel reken ik met de eenvoudige benadering: Vereiste werkers ≈ Gelijktijdige ongecacheerde verzoeken. Deze gelijktijdigheid wordt berekend door de aanvraagfrequentie te vermenigvuldigen met de gemiddelde verwerkingstijd. Voorbeeld: 10 requests/s met 300 ms servicetijd resulteren in ongeveer 3 gelijktijdige PHP requests. Als ik rekening houd met veiligheidsreserves en korte pieken, verdubbel ik deze waarde. Belangrijk: Dit getal moet CPU-kernen en RAM fit; een werker zonder CPU-tijd is gewoon een wachtende werker.
Bereken je opslagbudget op de juiste manier
Elk PHP-FPM proces verbruikt RAM, afhankelijk van PHP versieactief Opcache en de geladen plugins. Ik meet de werkelijke voetafdruk onder belasting (ps/top) en vermenigvuldig deze met pm.max_kinderenweb server, database en cache services toevoegen. Zo voorkom ik swapping en de OOM-killer. Als regel houd ik 20-30% vrije RAM buffer. Als het verbruik per proces significant toeneemt, interpreteer ik dit als een signaal voor Plugin-dieetminder uitbreidingen of meer beperkende geheugenlimietinstellingen per pool.
Caching als reliëflaag
Hoe meer ik leer van de Cache hoe minder energie de werkers verbruiken. Pagina cache, object cache en edge cache verminderen de PHP-uitvoering drastisch. Dynamische onderdelen zoals het winkelwagentje of gepersonaliseerde blokken sluit ik in met ESI of Ajax, zodat de rest in de cache blijft. Als je dieper wilt gaan, kun je het volgende vinden Server-side caching Gids nuttige strategieën voor NGINX en Apache die werkers echt ontlasten. Dit is hoe ik de TTFB merkbaar verlaag en de Reactietijd laag onder belasting.
Ik houd ook rekening met Cache ongeldig maken en opwarmstrategieën: Na implementaties of grote productwijzigingen warm ik kritieke pagina's en API-routes op. In shops laad ik categoriepagina's, bestsellers, de startpagina en preloads voor de kassa om koude startpieken op te vangen. Voor object caches let ik op schone sleutelstrategieën zodat ik niet onnodig hotsets weggooi.
Typische fouten en dure valkuilen
Velen vermoeden in eerste instantie een gebrek aan RAM of CPU als het grootste probleem, hoewel de wachtrij van de werkers de werkelijke bottleneck is. Ik controleer daarom of pagina's in de cache snel blijven en of alleen dynamische paden uit de hand lopen. Een andere misvatting is "meer workers lost alles op", wat zonder extra cores leidt tot hoge context switches en slechtere latency. Evenzo binden slechte plugins een worker voor een buitensporig lange tijd, waardoor de waargenomen latency toeneemt. Prestaties verslechtert. Daarom verminder ik add-ons, optimaliseer ik databasequery's en schaal ik resources samen.
WordPress-specifieke hotspots
- admin-ajax.php en wp-jsonVeel kleine oproepen stapelen zich op en blokkeren werkers; ik bundel verzoeken en stel verstandige caches in.
- Heartbeat API: In de backend beperk ik de frequenties zodat er niet onnodig veel gelijktijdige verzoeken zijn.
- WooCommerce wc-ajaxWinkelwagen-, verzend- en couponcontroles worden vaak niet gecached; ik verminder externe API-aanroepen en optimaliseer hooks.
- Transiënten en OptiesOvervolle autoload opties of dure transiënte regeneraties verlengen de PHP runtime en dus de slot commitment.
Praktijk: Van drie tot acht werknemers - zonder opstoppingen
Ervan uitgaande dat een winkel slechts drie Werknemer en 's avonds last heeft van vastgelopen kassa's. Ik analyseer eerst paden die niet uit de cache komen en meet de TTFB onder belasting. Vervolgens activeer ik clean page en object caching en besteed ik alleen gepersonaliseerde gebieden uit. Vervolgens verhoog ik het aantal werkers naar acht en voeg tegelijkertijd twee extra CPU-kernen gratis. In de volgende belastingstest nemen de wachtrijen af en daalt de foutmarge aanzienlijk.
Optioneel kan ik ook pieken afvlakken door conservatieve limieten in te stellen voor dure eindpunten in de webserver (bijvoorbeeld lage gelijktijdige upstreams voor afrekenen), terwijl ik statische en gecachete inhoud op onbeperkte snelheid aflever. Dit haalt de druk van de FPM-pool en stabiliseert de TTFB over de hele linie, zelfs als individuele gebruikersacties even langzamer zijn.
Monitoring en belastingstesten: tools die ik gebruik
Ik volg TTFBde responstijd en foutfrequentie met korte intervallen om congestie in een vroeg stadium te detecteren. Voor synthetische belasting gebruik ik tools als K6 of Loader omdat die realistische pieken genereren. Toepassingslogs helpen om langzame queries en externe API-aanroepen te identificeren die werkers ophouden. Ik controleer ook PHP FPM statuspagina's om bezette, wachtende en vrije slots in de gaten te houden. Als slots permanent vol raken, verhoog ik de workers en CPU stap voor stap en controleer elke stap met een testbelasting.
Metriek betrouwbaar interpreteren
- max. bereikte kinderenDe bovenlimiet is bereikt; aanvragen wachten - tijd voor meer werkers of snellere caching.
- luisterwachtrijEen groeiende wachtrij bevestigt congestie voor FPM; ik controleer de webserver en upstream instellingen.
- verzoek_slowlog_timeout en slowlog: Identificeert de exacte verzoeklocaties waar werkers zijn aangekoppeld.
- upstream_antwoord_tijd in webserverlogboeken: Toont hoe lang PHP heeft gereageerd; ik correleer met verzoek_tijd en statuscodes (502/504).
Specifieke upgradesignalen correct interpreteren
Als de TTFB Als er een merkbare toename in verkeer is ondanks actieve caching, is er meestal een gebrek aan werkcapaciteit. Als er regelmatig 504 fouten optreden tijdens acties zoals afrekenen of inloggen, is er echt sprake van verkeersopstoppingen. Meer gelijktijdige bestellingen, spontane campagnes of lanceringen rechtvaardigen extra werkers zodat transacties soepel verlopen. Als de 503 foutstatus optreedt, is het de moeite waard om deze gids te bekijken om WordPress 503 foutmeldingomdat foutieve processen en limieten vergelijkbare effecten hebben. Vervolgens beslis ik of ik Worker ga gebruiken, CPU of time-outs.
Configuratie: PHP-FPM en zinnige limieten
Met PHP-FPM bepaal ik met pm.max_kinderen het maximum aantal gelijktijdige processen en dus de bovengrens van de workers. Ik gebruik pm.start_servers en pm.min/max_spare_servers om te bepalen hoe snel capaciteit beschikbaar is. pm.max_requests beschermt tegen geheugenlekken door processen opnieuw te starten na X verzoeken. request_terminate_timeout beveiligt lange lopers zodat een werker niet eeuwig blijft hangen en slots blokkeert, die ik zorgvuldig instel voor afrekenpaden. Deze instelschroeven hebben een direct effect op wachtrijen, dus ik verander ze alleen samen met Tests.
Ik kies de juiste pm-modus bewust: dynamisch voor fluctuerende belastingen, ondemand voor zeer sporadische belastingen op kleine instanties en statisch voor constant hoge pieken wanneer CPU en RAM duidelijk gereserveerd zijn. Ik activeer ook Opcache met voldoende geheugen en scripts efficiënt revalideren zodat werkers minder CPU per verzoek nodig hebben. Met verzoek_slowlog_timeout en slowlog Ik vind hotspots in de code zonder de pool te vergroten. Ik controleer of de FPM socket als Unix socket of TCP is verbonden; lokaal geef ik de voorkeur aan sockets, via containers/hosts vaak TCP.
Checklist voor winkels, lidmaatschappen en LMS
Voor winkels beschouw ik dynamisch Pagina's zoals het winkelmandje, de kassa en "Mijn account" en verminder externe oproepen. In ledengebieden controleer ik elke profiel- en dashboardquery op overbodige query's. In LMS vertrouw ik op object caching voor cursuslijsten, terwijl ik voortgangsindicatoren efficiënt render. In alle gevallen streef ik naar een paar korte requests per actie, zodat werknemers snel weer vrij zijn. Pas als dit huiswerk af is, breid ik werkers uit en CPU parallel.
Sessies, vergrendeling en concurrency vallen
Ik let op session locks, die in PHP standaard serieel per gebruikerssessie werken. Als dure acties (bijvoorbeeld callbacks voor betalingen) tijdens dezelfde sessie worden uitgevoerd, worden verdere aanvragen van deze gebruiker geblokkeerd, wat resulteert in pieken in TTFB en waargenomen hang-ups. Ik minimaliseer het gebruik van sessies, sla alleen het essentiële op in sessies en schakel over op krachtige handlers (bijv. in-memory). In WooCommerce besteed ik aandacht aan sessies en tijdelijke stormen in het winkelmandje.
Database en externe diensten als multipliers
Vaak traag SQL-query's of snelheidslimieten van externe API's de werker beïnvloeden. Ik optimaliseer indices, verminder N+1 queries, stel query caches in (object cache) en beperk externe calls met timeouts en retry logica. Als betaal-, dispatch- of licentieservers traag worden, beperk ik bewust het parallellisme op deze routes zodat niet de hele pool staat te wachten. Hierdoor blijven er vrije slots over voor andere gebruikersacties.
Provider selectie en hosting tuning met het oog op werknemers
Ik geef de voorkeur aan hostingplannen waarbij ik PHP-medewerkers flexibel en breiden CPU cores parallel uit. Leveranciers met hoge prestaties leveren schone cachingniveaus, snelle NVMe-opslag en duidelijke statistieken in het paneel. Als inleiding op de technische evaluatie PHP Hosting Gidsdie centrale criteria en opties tastbaar maakt. Voor mij is het belangrijk dat de ondersteuning niet wordt onderbroken tijdens verkeerspieken, maar dat er capaciteit beschikbaar is zonder opnieuw op te starten. Zo houd ik TTFB, foutpercentage en Doorvoer in balans.
Plan voor pieken en bescherming tegen botbelasting
Ik ben het van tevoren eens over een escalatiepad: hoe snel kunnen werknemers en CPU Wie bewaakt welke timeouts tijdelijk mogen groeien? Tegelijkertijd minimaliseer ik de belasting door bots en spam via verstandige limieten op dynamische eindpunten. Elk onnodig verzoek dat wordt afgeweerd is een gratis werkslot voor echte klanten.
Wegnemen
PHP-medewerkers bepalen hoe snel dynamische pagina's reageren onder belasting omdat elk proces slechts één verzoek per keer verwerkt. Ik minimaliseer de belasting met consistente caching, ruim blokkerende plugins op en zorg voor een verstandige worker-to-CPU-verhouding. Op piekmomenten verhoog ik de workers voorzichtig en test of de wachtrij verdwijnt en de TTFB daalt. Logboeken, FPM-status en belastingstesten geven me het bewijs of ik correct schaal of de time-outs moet aanscherpen. Als je deze hefbomen onder controle hebt, voorkom je bottlenecks, bescherm je transacties en zorg je voor een merkbaar snellere verwerkingstijd. Gebruikerservaring.
