Videre til indhold 
Jeg viser dig, hvordan du WordPress PHP-FPM så sidevisninger forbliver hurtige, selv under belastning, og serveren kører problemfrit. For at gøre dette bruger jeg specifikke parametre som f.eks. pm.max_børn, OPcache, sockets og timeouts og giver klare, pålidelige startværdier.
Centrale punkter
- pm.max_børn Realistisk beregning af RAM
- Dynamisk som tilstand for de fleste steder
- OPcache Aktiver og dimensionér
- Stik i stedet for TCP til Nginx/Apache
- Overvågning Brug til finjustering
Hvorfor PHP-FPM tæller med WordPress
Jeg er afhængig af PHP-FPM, fordi FastCGI Process Manager betjener anmodninger parallelt med arbejdsprocesser og dermed reducerer ventetiden markant; dette gør dynamisk WordPress-sider er betydeligt mere responsive. Sammenlignet med gamle handlere holder FPM CPU- og RAM-belastningen under kontrol, hvilket er særligt vigtigt under spidsbelastninger med mange samtidige anmodninger, og man undgår fejl. Plugins og temaer kræver hukommelse, så hvert barn har brug for en vis buffer, som jeg beregner og kontrollerer løbende. Med en smart pool-konfiguration arbejder jeg mig gennem udsving uden at producere tomgangstid eller overbelaste serveren. En ren tilgang her reducerer svartider, øger pålideligheden og holder serveren kørende. Opladningstid konstant lav.
Filer, pools og fornuftig struktur
Konfigurationen af FPM-poolen er normalt som følger /etc/php/[version]/fpm/pool.d/ eller /etc/php-fpm.d/, og jeg tjekker den nøjagtige sti via php -i for ikke at tweake den forkerte fil. Jeg bruger en separat pool til hvert websted, fordi isolerede processer forenkler fejlfinding og adskiller belastningen rent. Jeg definerer brugeren, socket-stien, procesadministratoren og alle grænseværdier i www.conf eller en projektspecifik pool.conf. Jeg navngiver sockets entydigt, f.eks. /run/php/siteA.sock, så Nginx peger specifikt på poolen, og jeg ikke risikerer at blande dem sammen. Denne klare adskillelse sikrer konsekvent Ressourcer-tildeling og stabile udrulninger.
Sikkerhed, rettigheder og ren poolisolering
Jeg satser pr. pulje bruger og gruppe til at matche webroden (f.eks. www-data), så filrettighederne forbliver konsekvente, og webserveren er autoriseret til at bruge soklen. Til Unix-sockets vælger jeg listen.ejer, listen.gruppe og listen.mode (0660), så Nginx/Apache kan få adgang til den på en pålidelig måde. Med clear_env=no Jeg tillader nødvendige miljøvariabler (f.eks. til eksterne tjenester) uden at slække på sikkerheden. security.limit_extensions til .php for at forhindre utilsigtet udførelse af andre filer. Eventuelt indstiller jeg chdir til projektets dokumentrod; chroot er muligt, men kræver en større arbejdsindsats og er ikke egnet til alle miljøer.
Vælg process manager-tilstande korrekt
Til de fleste installationer bruger jeg tilstanden dynamisk, fordi den fleksibelt absorberer spidsbelastninger og sparer ressourcer i tomgang. I statisk tilstand forbliver antallet af processer uændret, hvilket kan være nyttigt ved ekstremt ensartede høje belastninger, men det binder RAM. Ondemand starter kun processer, når det er nødvendigt, hvilket er nyttigt på meget små instanser, men forårsager koldstartforsinkelser. Valget afhænger af trafikprofilen: svingende trafik har gavn af dynamisk, konstante spidsbelastninger spiller sammen med statisk, og opsætninger med lav trafik kører ofte bedre med ondemand. Jeg træffer altid beslutningen i forbindelse med reelle målte værdier, fordi kun data viser, om en tilstand opfylder kravene. Belastning virkelig har på.
| Tilstand | Brug | Fordel | Hint |
|---|---|---|---|
| dynamisk | Svingende trafik | Fleksibel, god responstid | Solide startværdier er tilstrækkelige til begyndelsen |
| statisk | Meget konstant høj belastning | Forudsigelig udnyttelse af RAM | RAM skal være nok |
| ondemand | Lav grundbelastning | Økonomisk ved tomgang | Overvej koldstart |
CPU-kerner, I/O og den rigtige parallelisme
Jeg er opmærksom på balancen mellem CPU-kerner og blokerende operationer. WordPress-anmodninger venter ofte på I/O (database, filsystem, eksterne API'er), så antallet af børn kan overstige antallet af kerner. Til tunge CPU-tunge opsætninger (billedbehandling, rapporter) holder jeg mig tættere på 1-2x kerner, til I/O-tunge sites fungerer 2-4x kerner, så længe RAM og timeouts er indstillet korrekt. Jeg tester under belastning, om CPU'en sidder permanent fast på 100 % (for mange processer) eller er underudnyttet på trods af lang ventetid (I/O-flaskehals, manglende cache).
Beregn pm.max_children: Sådan gør jeg
Jeg starter med serverens RAM, det reelle forbrug pr. PHP-proces og en buffer til databasen og webserveren, så intet rammer loftet; på denne måde er meningsfuld Grænseværdier stabil med det samme. Eksempel: 4 GB RAM, 1 GB buffer til MySQL/Nginx/cache og Ø 100 MB pr. PHP-proces giver 30-35 børn, ikke 40, fordi jeg indregner reserver. Hvis du bruger mange hukommelseskrævende plugins, skal du planlægge 120-150 MB pr. proces og teste, om profilen passer. Ved spidsbelastninger orienterer jeg mig efter samtidige forespørgsler: Med omkring 50 parallelle besøg er 15-25 børn ofte nok, hvis caching og OPcache fungerer korrekt. Du kan finde en detaljeret udledning her: Optimer pm.max_children, Og jeg tager logikken fra det, ikke tallene blindt.
Vælg start-, reserve- og anmodningsparametre
Når det gælder dynamik, sætter jeg ofte pm.start_servers til 10, pm.min_spare_servers til 5 og pm.max_spare_servers til 20, fordi det giver en god balance mellem opstartsfasen og inaktivitetstiden. Svartid forbliver konstant. pm.max_requests med 300-800 forhindrer hukommelseslækager fra oppustede processer; 500 er en solid startværdi. Jeg øger pm.max_spare_servers, hvis der opstår ventende forespørgsler, og køen vokser. Hvis der er for mange inaktive processer, sænker jeg reserveværdierne, så der stadig er RAM til rådighed. Efter hver ændring overvåger jeg CPU, RAM, anmodningskøen og fejlloggene, ellers forbliver indstillingen et gæt i stedet for en klar beslutning.
Timeouts, version og hukommelsesgrænse
Jeg sætter normalt request_terminate_timeout til 60-120 sekunder, så hængende scripts afsluttes, og poolen forbliver fri; alt derover maskerer kun Fejl i koden eller i integrationer. Jeg holder PHP-versionen moderne, dvs. 8.1 eller 8.2, fordi nye versioner giver mærkbare præstationsforbedringer og bedre typesikkerhed. Memory_limit er ofte 256M eller 512M, afhængigt af plugin-landskabet og billedbehandlingen. Hvis du behandler mange høje opløsninger, skal du beregne reserver, teste uploads og overvåge logfilerne. I sidste ende er det, der tæller, om kombinationen af limit, requests og OPcache kører uden outliers og ikke kaster nogen out-of-memory-fejl.
OPcache: CPU-turboen til WordPress
Jeg udelader aldrig OPcache, fordi den holder kompileret PHP-bytekode i RAM og dermed sparer massiv CPU-tid; dette aflaster Arbejder og gør hver side hurtigere. I produktionen deaktiverer jeg tidsstempeltjek og tildeler nok hukommelse til cachen til at undgå konstante evictions. For mellemstore websteder er 128-192 MB ofte nok, mens større installationer har gavn af 256 MB og mere. Jeg overvåger hitraten med et OPcache-status-script, ellers er det uklart, om cachen er stor nok. Eksempler på værdier, der har vist sig at være vellykkede, kan ses her:
opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=10000
opcache.validate_timestamps=0
opcache.revalidate_freq=0
For WordPress slår jeg normalt JIT fra, fordi arbejdsbelastningen sjældent har gavn af det, men yderligere hukommelse ville blive bundet op. Efter implementeringer varmer jeg cachen op med de vigtigste ruter eller WP-CLI-kommandoer, så de første brugere ikke oplever nogen kompileringsoverhæng.
Nginx/Apache: Socket i stedet for TCP og valg af handler
Jeg bruger Unix-sockets mellem webserveren og FPM, fordi det lokale socket-kald har mindre overhead end TCP og dermed sparer noget ventetid; dette betaler sig direkte på Ydelse i. I Nginx ser det nogenlunde sådan ud: fastcgi_pass unix:/run/php/wordpress.sock;. I Apache med Proxy-FastCGI fungerer socken også, så længe tilladelserne er korrekte. Jeg tjekker også den aktive PHP-handler og vælger FPM frem for gamle varianter. Hvis du vil forstå forskellene mere detaljeret, kan du klikke dig igennem denne oversigt: Sammenlign PHP-håndteringer, for at undgå misforståelser om mod_php, FPM og proxy-varianter.
Webserverparametre, der matcher FPM-puljen
Jeg tilpasser Nginx/Apache-timeouts til FPM-værdierne, så intet lag afsluttes for tidligt. fastcgi_read_timeout Jeg orienterer mig efter request_terminate_timeout (f.eks. 120s), fastcgi_connect_timeout Jeg holder dem korte (1-5s). Tilstrækkelig fastcgi_buffere forhindre 502/504 for store svar. Jeg sætter keep-alive- og worker-grænser realistisk: mange meget lange keep-alive-forbindelser blokerer ellers slots, som PHP-backends har brug for. Under Apache bruger jeg Event-MPM, begrænser MaxRequestWorkers til at matche RAM og sørger for, at FPM kan levere flere børn, end webserveren sender til backend-behandleren parallelt - ellers vil frontend-klienter blive overrasket i køen.
Målrettet brug af overvågning og FPM-status
Jeg måler løbende, ellers forbliver tuning en ren mavefornemmelse og rammer det rigtige mål. Årsag ofte ikke. htop/top viser hurtigt, om RAM er ved at være brugt op, om processer thrasher, eller om CPU-kernerne er korrekt udnyttet. PHP FPM's statusside afslører køens længde, aktive og ventende processer og den gennemsnitlige behandlingstid pr. anmodning. Hvis køen og ventetiden vokser, mangler der som regel processer, eller caching fungerer ikke. Hvis du er interesseret i parallelle processer, er dette et godt sted at starte: PHP-Worker flaskehals, fordi antallet af arbejdere i sidste ende begrænser de samtidige PHP-anmodninger pr. instans.
Slowlog, backlog og stabil fejldiagnose
For at finde outliers aktiverer jeg Slowlog pr. bassin og sæt request_slowlog_timeout til 3-5 sekunder. Det giver mig mulighed for at se, hvilke scripts der hænger, og om eksterne opkald gør tingene langsommere. Med catch_workers_output notices/warnings pr. proces ender i pool-loggen, hvilket fremskynder analysen af grundårsagen. Derudover indstiller jeg socketlisten.backlog høj (f.eks. 512-1024), så korte toppe ikke fører direkte til 502; jeg korrelerer dette med kernens backlog (somaxconn), så køen ikke fejler på grund af operativsystemet. Hvis logfiler ofte indeholder “server nåede pm.max_children” eller “Poolen virker optaget”, er enten paralleliteten for lav, eller også ligger den egentlige årsag i databasen/eksterne tjenester.
Hyppige snublesten og hurtige løsninger
Mange problemer gentager sig i lignende mønstre, så jeg har altid typiske symptomer, årsager og modforanstaltninger klar, så jeg ikke behøver at starte forfra hver gang og miste værdifuld tid. Tid taber. Høje svartider, 502-fejl eller hukommelsesfejl indikerer normalt forkert indstillede procesnumre, forkerte reserveværdier eller overfyldte scripts. I praksis hjælper det kun at ændre én variabel pr. runde og derefter kontrollere målingerne. Den, der glemmer OPcache eller sætter max requests til uendelig, betaler ofte prisen med snigende hukommelseslækager. Følgende tabel opsummerer de mest almindelige tilfælde:
| Problem | Årsag | Løsning |
|---|---|---|
| Høj responstid | For få max_børn | Genberegn og øg pm.max_children |
| 502 Dårlig gateway | Puljen er fuldt udnyttet, eller reserveværdierne er for små | Forøg pm.max_spare_servers og tjek logfiler |
| Tilladt hukommelsesstørrelse opbrugt | Utætte scripts eller memory_limit for lav | Reducer pm.max_requests, tjek OPcache, øg grænserne |
| Langsom koldstart | ondemand ved spidsbelastning | Skift til dynamisk og øg start-/reserveværdierne |
Afhjælpning af WordPress-specifikke belastningsdrivere
Jeg tjekker typiske hotspots: admin-ajax.php, wp-json og heartbeat-ruter. Højfrekvente AJAX- eller REST-endepunkter kan binde poolen op, hvis caching træder i kraft, men er nødt til at lade disse ruter komme igennem. Kortere timeouts, rene objektcacher og prioritering kan hjælpe her: Jeg kører eventuelt en separat pool med et mindre antal børn til /wp-admin/ og /wp-login.php, så den offentlige pool forbliver performant selv under redaktionelle spidsbelastninger. wp-krone Jeg afkobler fra besøgstrafikken (real system cron), så langvarige opgaver ikke tilfældigvis falder sammen med brugeradgange. Med en vedvarende objektcache (Redis/Memcached) reduceres DB-belastningen betydeligt; det betyder, at pm.max_børn ofte lavere uden at miste ydeevne.
Opsætning med høj trafik: Caching, database- og servertuning
Når der er meget trafik, kombinerer jeg FPM-tuning med aggressiv sidecaching, så kun en brøkdel af forespørgslerne når PHP og Svartid forbliver forudsigelig. En reverse proxy-cache eller et solidt WordPress-cache-plugin reducerer ofte dynamiske hits drastisk. Gzip eller Brotli på webserveren sparer båndbredde og reducerer time-to-first-byte for tilbagevendende ressourcer. Jeg holder databasen slank: holder øje med autoload-muligheder, rydder op i transienter og kører overvågning af forespørgsler. Disse moduler øger den effektive kapacitet pr. instans betydeligt, uden at det er nødvendigt at ændre hardwaren.
Kontrollér modtryk og undgå overbelastning
Jeg definerer bevidst, hvor forespørgsler venter: Jeg foretrækker, at de er i webserverens kø i stedet for i FPM-poolen. For at gøre dette beholder jeg listen.backlog moderat og begræns webserverarbejderne, så de ikke oversvømmer puljen ukontrolleret. Et for stort efterslæb skjuler flaskehalse og øger latenstiden. En for lille backlog fører til 502-fejl. Jeg kan genkende den „rigtige“ størrelse i status: Hvis listekøen i FPM sjældent ser spidsbelastninger, og svartiderne stadig forbliver stabile, er balancen rigtig.
Udrulninger, genindlæsninger og nul nedetid
Jeg foretrækker Genindlæsninger i stedet for hårde genstarter, så kørende forespørgsler afsluttes rent. I FPM kontrollerer jeg dette med process_control_timeout, så børnene har tid til en ordentlig nedlukning. Når koden er implementeret, tømmer jeg ikke OPcachen i blinde, men varmer den specifikt op eller accepterer en kort blandingsfase med validate_timestamps=1 for blå/grønne strategier. Vigtigt: Webserveren skal have en elegant genindlæsning Ellers risikerer du korte 502-vinduer, selv om puljen fortsat fungerer korrekt.
Udvidede noter til virtualisering og multi-sites
På virtuelle eller container-værter bemærker jeg, at målte RAM-størrelser og CFS-kvoter er de effektive Strøm Det er derfor, jeg aldrig kører pm.max_children op til beregningsgrænsen. Jeg adskiller multi-site-miljøer efter pool, så et varmt projekt ikke bremser de andre. Ved stærkt svingende trafik er automatisk skalering med flere små instanser ofte bedre end én stor maskine. Delt NFS eller fjernlager udvider filadgangen; OPcache og lokale uploads buffer en stor del af den. Det betyder, at platformen forbliver forudsigelig, selv om enkelte sites bryder ud.
Læsning og korrekt fortolkning af konkrete nøgletal
I FPM-status ser jeg primært på de kørende, ventende og samlede processer, fordi disse tre tal repræsenterer FPM's status. Pools kan opsummeres hurtigt. En permanent voksende kø signalerer underforsyning eller et manglende cache-hit. Hvis CPU'en står stille, selvom forespørgsler venter, blokerer I/O eller eksterne tjenester ofte; profilering og timeouts kan hjælpe her. Hvis processer konstant genstarter, er pm.max_requests for lav, eller et plugin lækker hukommelse. Jeg genkender sådanne mønstre, verificerer dem med logfiler, og først derefter justerer jeg de relevante parametre.
Andre praktiske værdier, som jeg holder øje med
Jeg værdsætter „max antal børn nået“ tæller, gennemsnitlig behandlingstid pr. anmodning og den maksimale listekø. Hvis „i tomgang“ er permanent meget høj i FPM-status, spilder jeg RAM - så reducerer jeg reserveværdierne eller antallet af børn. Akkumuler „langsomme anmodninger“ tyer jeg først til slowlog-analyse og tjekker DB-forespørgsler, eksterne API'er og billedbehandling. I Nginx/Apache observerer jeg åbne forbindelser, keep-alive-varighed og fejlkoder; 499/408 indikerer klientnedbrud (langsomme netværk, mobil), 504 snarere for korte backend-timeouts.
I en nøddeskal: essensen af hurtige WordPress PHP FPM-opsætninger
Jeg beregner pm.max_children konservativt, bruger dynamisk, sætter start/spare-værdier fornuftigt og holder OPcache stor nok til, at koden i Cache er tilbage. Sockets i stedet for TCP reducerer latency, timeouts eliminerer hangs, og moderne PHP-versioner skubber performance fremad. Overvågning giver sandheden om køer, hukommelse og svartid; jeg måler alle ændringer i forhold til det. Med en cache før PHP, en sund database og en solid FPM-konfiguration forbliver webstedet hurtigt og pålideligt. Hvis du anvender denne tilgang konsekvent, vil du få mest muligt ud af WordPress PHP-FPM på lang sigt.
