PHP verzoekwachtrijen beperken hoeveel verzoeken je server tegelijkertijd verwerkt en bepalen daardoor de responstijd, foutpercentages en gebruikerservaring. Ik laat je zien hoe je Verwerkingslimieten en knelpunten te elimineren en een consistente levering te realiseren door middel van geharmoniseerde parameters.
Centrale punten
Zodat je meteen aan de slag kunt, geef ik een overzicht van de belangrijkste stelschroeven voor PHP-FPM samen.
- pm.max_kinderenBereken de bovengrens voor gelijktijdige PHP-processen zodat deze overeenkomt met het RAM-geheugen.
- listen.backlogMaximaliseer kortetermijnbuffering van verbindingspogingen tijdens piekbelastingen.
- pm.max_aanvragenRecycle processen regelmatig om geheugenlekken en bloat te voorkomen.
- Time-outsStel request_terminate_timeout, max_execution_time en webserver timeouts consistent in.
- Metriekmax kinderen bereikt, controleer dan continu de luisterwachtrij en de slowlogs.
Ik richt me op duidelijke kengetallen en meetbare effecten, zodat elke aanpassing aan Grenzen traceerbaar blijft. Voor elke verandering controleer ik de logs en reactietijden voordat ik de volgende stap plan en de waarden geleidelijk verhoog of verlaag. Op deze manier voorkom ik neveneffecten zoals het verwisselen van geheugen, dat Wachtrij dramatisch langer. Met deze aanpak breng ik belastingspieken onder controle en houd ik de responstijden stabiel. Het doel is om een gebalanceerd capaciteitsgebruik te bereiken dat Bronnen efficiënt zonder de host te overbelasten.
Hoe PHP Request Queueing werkt in PHP-FPM
Elk inkomend HTTP-verzoek heeft zijn eigen Werknemer, en een werker dient maar één verzoek per keer in. Als alle processen bezet zijn, komen verdere verzoeken terecht in de Wachtrij en wachten tot er een proces vrij komt. Als deze wachtrij groeit, nemen de reactietijden toe en komen fouten zoals 502/504 vaker voor. Ik let daarom op een verstandige verhouding tussen het aantal processen en het beschikbare geheugen in plaats van me blind te staren op maximaal parallellisme. Op deze manier bereik ik een constante doorvoersnelheid zonder RAM of CPU afbreken.
Procesbeheermodi netjes selecteren
Naast de grenswaarden zijn de pm-modus reactievermogen en verbruik van bronnen:
- pm = dynamischIk definieer start_servers, min_spare_servers en max_spare_servers. Deze modus is mijn standaard voor variabele belastingen omdat het snel reageert op verhogingen en warme processen gereed houdt.
- pm = ondemandProcessen worden alleen aangemaakt wanneer dat nodig is en worden beëindigd na process_idle_timeout. Dit bespaart RAM voor infrequente toegang (admin, staging, cron eindpunten), maar kan leiden tot verlies van RAM in het geval van plotselinge pieken. koude starts en hogere latency. Ik gebruik het daarom selectief en met een royale achterstand.
- pm = statischEen vast aantal processen. Ideaal als ik een harde bovengrens en bijzonder voorspelbare latenties (bijv. L7 proxy voor een paar maar kritieke eindpunten). De RAM-behoefte is duidelijk te berekenen, maar ongebruikte processen nemen geheugen in beslag.
Ik beslis voor elke pool welke modus bij het profiel past. Ik gebruik meestal dynamisch voor frontends met wisselende belasting, ondemand voor utility pools en statisch voor toegewijde, latency-kritische diensten.
Bepaal pm.max_children correct
De belangrijkste hefboom is pm.max_kinderen, omdat deze waarde bepaalt hoeveel verzoeken tegelijkertijd kunnen worden uitgevoerd. Ik bereken de startgrootte met de vuistregel: (vrij beschikbaar RAM - 2 GB reserve) gedeeld door het gemiddelde geheugen per PHP proces. Als ruwe aanname gebruik ik 40-80 MB per proces en begin met 200-300 processen op een 32 GB host. Onder live belasting verhoog of verlaag ik geleidelijk en controleer ik of de wachttijd van de Wachtrij daalt en de foutmarge daalt. Als je dieper wilt graven, kun je achtergrondinformatie over start- en grenswaarden vinden op pm.max_children optimaliseren.
Start-, reserve- en achterstandswaarden coördineren
Ik stel pm.start_servers tot ongeveer 15-30 procent van pm.max_children zodat er genoeg processen beschikbaar zijn bij de start en er geen koude starts zijn. Met pm.min_spare_servers en pm.max_spare_servers definieer ik een redelijk venster voor vrije processen zodat nieuwe verzoeken niet hoeven te wachten en er tegelijkertijd geen onnodig ongebruikt geheugen in beslag wordt genomen. Listen.backlog is bijzonder belangrijk: Deze kernelbuffer houdt kort extra verbindingspogingen vast als alle werkers bezet zijn. Voor belastingspieken stel ik hoge waarden in (bijv. 65535) zodat de wachtrij niet stopt voor de FPM-pool. Meer diepgaande achtergrondinformatie over de interactie tussen de webserver, upstream en buffers kan gevonden worden in het overzicht van Webserver in de wachtrij.
Runtimes van verzoeken beperken en processen recyclen
Ik voorkom sluipende geheugenpieken met pm.max_aanvragen, die elk proces herstart na X verzoeken. Onopvallende applicaties draaien vaak goed met 500-800, als geheugenlekken worden vermoed verlaag ik het naar 100-200 en observeer het effect. Daarnaast vangt request_terminate_timeout uitschieters op door extreem langlopende verzoeken na een vaste tijd te beëindigen. Consistentie is belangrijk: ik houd PHP's max_execution_time en de webserver timeouts in dezelfde gang zodat de ene laag niet eerder eindigt dan de andere. Deze interactie houdt de Werknemer vrij en beschermt het zwembad tegen opstoppingen.
Maak wachtrijen zichtbaar: Logboeken en statistieken
Ik lees regelmatig de FPM logs en let op max. bereikte kinderen, omdat dit aangeeft dat de bovengrens van de processen is bereikt. Tegelijkertijd monitor ik de luisterwachtrij, die een toenemende achterstand in de invoerbuffer laat zien. In combinatie met request_slowlog_timeout krijg ik stack traces voor trage punten in de code en kan ik database of API remmen isoleren. Ik correleer upstream_response_time uit de webserverlogs met request_time en statuscodes om de bron van lange responstijden te achterhalen. Hierdoor kan ik herkennen of het knelpunt in PHP-FPM, de Database of het stroomopwaartse netwerk.
Werklastprofielen: CPU-gebonden vs. IO-gebonden
Voor CPU-zware processen schaal ik de Parallellisme Ik ben voorzichtig en oriënteer me sterk op het vCPU-getal, omdat extra processen nauwelijks doorvoer opleveren. Als het vooral een IO-belasting is met databasetoegangen of externe API's, kan ik meer processen toestaan zolang het RAM-budget voldoende is. E-commerce checkouts hebben baat bij langere timeouts (bijv. 300 s) om betaalmethoden te voltooien zonder annuleringen. Ik onderschep flitsverkopen door listen.backlog hoog in te stellen en het reservevenster te vergroten. Informatie over de balans tussen het aantal processen en de prestaties van de host is gebundeld in de handleiding voor PHP-Workers als knelpunt.
Voorbeeldberekeningen en dimensionering
Ik bereken eerst het geheugen per proces en leid dan een redelijke Bovengrens uit. Ik test dan onder echte belasting en kijk of de wachtrij afneemt en de doorvoer toeneemt. Conservatieve beginwaarden verminderen het risico op verwisselen en houden de responstijd gelijk. Vervolgens verfijn ik in kleine stapjes om er zeker van te zijn dat ik geen neveneffecten opmerk. De volgende tabel geeft richtlijnen voor startwaarden en effecten op de Wachtrij.
| Parameters | Effect | Beginwaarde (voorbeeld) | Tip |
|---|---|---|---|
| pm.max_kinderen | Max. gelijktijdig Processen | 200-300 (met 32 GB) | Vergelijken met RAM-budget en procesgrootte |
| pm.start_servers | Initieel aantal werknemers | 15-30 % van max_children | Vermijd een koude start, maar beperk stationair draaien tot een minimum |
| pm.min_spare_servers | Gratis Werknemer Minimaal | z. B. 20 | Directe opname van nieuwe verzoeken |
| pm.max_spare_servers | Vrije werknemer Maximum | z. B. 40 | RAM-verbruik van inactieve processen beperken |
| listen.backlog | Kernelbuffer voor verbindingspogingen | 65535 | Piekbelastingen opvangen en verbindingsonderbrekingen verminderen |
| pm.max_aanvragen | recycling Interval | 500-800, met lekkages 100-200 | Minimaliseer geheugenopgeblazenheid en hangen |
| verzoek_terminate_timeout | Harde aanvraaglimiet | 300-600 s | Consistent met time-outs van PHP en webservers |
Praktische sjablonen voor PHP FPM-pools
Voor een winkel met veel leestoegang stel ik gematigd Procescijfers en verhoog het reservevenster zodat verzoeken niet in de wachtrij komen te staan. Voor inhoudspagina's met caching zijn aanzienlijk minder werkers vaak voldoende zolang NGINX of Apache statische inhoud efficiënt levert. Ik scheid multi-pool setups volgens applicatieonderdelen die verschillende geheugenprofielen hebben, zodat geen enkele zware pool de andere verdringt. Ik definieer aparte pools met hun eigen timeout regels voor cron of queue workers. Zo houd ik de interactieve Verkeer gratis en vertraagt gebruikersacties niet.
Time-outs webserver, upstream en sockets
Ik beschouw FastCGI en proxy timeouts van Nginx of Apache in hetzelfde venster als de timeouts van de FPM zodat geen enkele laag te vroeg eindigt. Ik geef de voorkeur aan Unix sockets boven TCP als beide diensten op dezelfde host draaien, omdat de latency minimaal blijft. Voor gedistribueerde opstellingen gebruik ik TCP met stabiele keepalive waarden en een voldoende grote verbindingspool. Voor hoge parallelliteit synchroniseert nginx worker_connections en de FPM backlog waarden. Dit zorgt ervoor dat redirects snel blijven en ik voorkom inactieve tijd door te krappe verbindingen. Upstream-limieten.
Caching, OPCache en database als hefbomen
Ik los veel serverproblemen op door dure bewerkingen te verminderen en de Reactietijd lager. Ik schakel OPCache in, verhoog de geheugenlimiet van de cache op een verstandige manier en zorg voor een hoge hitrate van de cache. Voor terugkerende resultaten gebruik ik applicatiecaching zodat PHP-processen sneller worden voltooid. Aan de databasezijde optimaliseer ik langzame query's en activeer ik querycaches die geschikt zijn voor het gebruikte systeem. Elke bespaarde milliseconde vermindert de belasting van de Wachtrij en verhoogt de verwerkingscapaciteit per werknemer.
Veilige noodmechanismen en herstarts
Ik activeer emergency_restart_threshold en emergency_restart_interval zodat de FPM master herstart als te veel kinderen kort na elkaar crashen. Deze gecontroleerde herstart voorkomt kettingreacties en houdt de dienst beschikbaar. Tegelijkertijd stel ik duidelijke limieten in voor het geheugen en het aantal processen om escalaties te voorkomen. Gezondheidscontroles aan de upstream kant verwijderen automatisch defecte backends uit de pool en verlagen het aantal fouten. Dit houdt de Beschikbaarheid terwijl ik de werkelijke oorzaak onderzoek.
Beperkingen van besturingssysteem en systemd fijn afstellen
Dus dat listen.backlog daadwerkelijk effect heeft, pas ik de kernellimieten aan. De OS-waarde net.core.somaxconn moet minstens even hoog zijn als de ingestelde achterstand, anders sluit het systeem de wachtrij af. Ik controleer ook het aantal toegestane bestandsdescriptors: In de FPM pool kan ik rlimit_files instellen, op serviceniveau zorg ik voor LimitNOFILE (systemd) en op kernelniveau fs.file-max. De webserver heeft vergelijkbare reserves nodig zodat hij niet eerder zijn limieten bereikt.
Voor stabielere latenties verlaag ik vm.swappiness, zodat de kernel actief gebruikte geheugenpagina's niet voortijdig verplaatst. In latentiekritische opstellingen deactiveer ik Transparante enorme pagina's, om lange paginafouten te voorkomen. Als FPM via TCP draait, synchroniseer ik ook net.ipv4.tcp_max_syn_backlog en reuse/keepalive parameters. Zulke details van het besturingssysteem lijken onopvallend, maar ze bepalen of wachtrijen glad verlopen of dat verbindingen al geweigerd zijn voor de FPM.
Geheugenbelasting per proces meten
In plaats van algemene schattingen te maken, meet ik de Reële consumptie per werker onder echte belasting. Ik gebruik tools als ps, smem of pmap, filter op php-fpm children en bereken het gemiddelde van de RSS-waarden terwijl de requests lopen. Het is belangrijk om rekening te houden met het gedeelde OPCache-gebruik: gedeeld geheugen wordt niet meerdere keren geteld. Ik leid pm.max_children af van de gemiddelde waarde en plan ook een reserve zodat de machine zelfs tijdens pieken niet in de knel komt. Swapping kantelt.
Ik herhaal deze meting na functie- of releasewijzigingen. Nieuwe functies, meer afhankelijkheden of wijzigingen in frameworks kunnen de voetafdruk per proces aanzienlijk vergroten. Dit houdt het aantal processen realistisch en de wachtrij kort.
PHP FPM status, ping en live statistieken
Voor een snelle beoordeling van de situatie activeer ik pm.status_path en een Ping eindpunt (ping.path/ping.response). Ik kan belangrijke cijfers zien zoals geaccepteerde conn, luisterwachtrij len, inactieve/bezette processen, max. bereikte kinderen en hun voortgang. Ik lees deze waarden periodiek en stel drempelwaarden in: als de luisterwachtrij permanent toeneemt, verhoog ik de processen of elimineer ik de oorzaak van trage verzoeken. Als max. bereikte kinderen omhoog springt terwijl idle laag blijft, is de pool te klein of geblokkeerd door lange lopers.
Ik scheid ook pools met verschillende profielen zodat pieken in één gebied (bijvoorbeeld API import) interactief verkeer niet op de knieën krijgt. Voor diagnostische gevallen verhoog ik tijdelijk het log_level en laat het slowlog meer samples vastleggen, maar verlaag het daarna weer om de I/O-belasting laag te houden.
Uploaden, bufferen en grote aanvragen
Grote uploads kunnen werkers onnodig ophouden als PHP eerst de verzoektekst moet lezen. Ik zorg ervoor dat de webserver buffers (bijvoorbeeld fastcgi_request_buffering voor NGINX), zodat FPM pas start als de body compleet is. Dit betekent dat er geen werker blokkeert tijdens het uploaden. Ik gebruik client_max_body_size, post_max_size en max_input_time om te bepalen hoe groot en hoe lang verzoeken kunnen zijn zonder eindpunten in gevaar te brengen. Als er bestanden tussen zitten, wijs ik voldoende snel temp-geheugen (SSD) toe om bufferopstoppingen te voorkomen.
Voor eindpunten met erg grote bestanden (bijv. exports/imports) definieer ik speciale pools met hun eigen timeouts en minder parallellisme. Dit laat de standaard werkers vrij en de Wachtrij van de belangrijke gebruikersacties.
Databaseverbindingen en poolgrenzen
Zelfs de beste FPM-instelling is nutteloos als de Database voorheen beperkt. Ik stem het maximum aantal gelijktijdige PHP processen af op de werkelijk beschikbare DB capaciteit. Voor persistente verbindingen of verbindingspools zorg ik ervoor dat de som van alle pools is op max_connections blijft. Als er veel korte queries zijn, helpt het om het PHP parallellisme matig te beperken zodat de DB niet heen en weer schudt tussen duizenden sessies.
Trage transacties veroorzaken snel een achterstand in de FPM wachtrij. Ik analyseer daarom lockwachttijden, indexgebruik en queryplannen. Elke verlaging van de DB-runtime verlaagt onmiddellijk de PHPDuur van het document en vermindert de wachtrijlengte.
Releases en rollouts zonder piek
Bij het uitrollen van nieuwe versies vermijd ik cold caches en process storms. Ik gebruik herladen in plaats van harde herstarts, zodat bestaande worker requests netjes eindigen (let op process_control_timeout). Ik warm de OPCache in een vroeg stadium op door kritieke paden een keer uit te voeren voordat ik overschakel of door te werken met preloading. Dit voorkomt dat veel workers tegelijkertijd klassebestanden parseren en de Reactietijd neemt met sprongen toe.
Met blauw/groene of kanarie-strategieën verhoog ik geleidelijk de belasting en houd ik de statuspagina's in de gaten. Pas als de wachtrij, het foutpercentage en de latentie stabiel blijven, verhoog ik het aandeel verkeer. Deze gecontroleerde aanpak beschermt tegen belastingspieken tijdens de implementatie.
Container- en VM-specialiteiten
In containers is de waargenomen Totaal opslagvolume vaak lager dan de host rapporteert. Ik stem pm.max_children strikt af op de cgroup limiet en plan een reserve tegen de OOM killer. Geheugenlimieten in PHP (memory_limit) en de footprint per proces moeten overeenkomen, anders is een enkele uitschieter genoeg om de container te beëindigen.
Als er geen swap in de container zit, zijn harde annuleringen waarschijnlijker. Daarom houd ik de processen conservatief, activeer ik recycling en monitor ik de RSS pieken in de productiebelasting. Verschillende slanke pools zijn hier vaak robuuster dan één grote, monolithische pool.
Controleerbare degradatie en tegendruk
Als de Wachtrij Ik vertrouw op gecontroleerde degradatie: ik lever bewust 503 met retry after voor niet-kritische eindpunten in het geval van overbelasting, beperk dure functies (zoals live zoeken) en beperk parallelle toegang tot hotspots. Hierdoor blijft het systeem responsief terwijl ik de oorzaak verhelp in plaats van dat alle gebruikers in time-outs terechtkomen.
Kort samengevat
Ik breng PHP verzoek in wachtrij onder controle door het aantal gelijktijdige processen slim af te stemmen op het RAM-budget en het type belasting. Hoge achterstandswaarden bufferen pieken, timeouts op alle niveaus sluiten netjes op elkaar aan en recycling verwijdert sluipende geheugenproblemen. Logs en statistieken laten me zien of de wachtrij groeit, waar verzoeken vastlopen en wanneer ik moet aanscherpen. Met zorgvuldige aanpassingen en gerichte caching verkort ik de verwerkingstijd per verzoek en verhoog ik de doorvoer. Op deze manier leveren servers consistent en vermijden ze dure Time-outs in het dagelijks leven.
