PHP-FPM Slowlog correct analyseren: prestatieknelpunten betrouwbaar opsporen

Ik laat je zien hoe je de PHP-FPM-slowlog doelgericht uitleest, de backtraces correct interpreteert en daaruit duidelijke stappen afleidt om de latentie te verminderen. Zo vind je op betrouwbare wijze prestatieknelpunten, stel je prioriteiten voor maatregelen en zorg je ervoor dat de laadtijden voor gebruikers merkbaar sneller worden.

Centrale punten

• Backtrace lees: Frame #0 geeft de huidige remblokpositie weer.
• Time-out Kies: eerst hoog beginnen en vervolgens stapsgewijs verlagen.
• Correlatie met access-log: trage URL’s nauwkeurig toewijzen.
• Voorbeeld tellen: prioriteit geven aan terugkerende taken.
• Code-correcties afleiden: DB, API's, loops en plug-ins doelgericht aanpakken.

Wat is het PHP-FPM-slowlog?

De Slowlog schrijft voor lange verzoeken een Backtrace in een logbestand en legt zo het huidige uitvoeringspunt vast, zonder het verzoek te beëindigen. Ik zie hieraan meteen welk script, welke URL en welke functie de weg blokkeert. De vermeldingen bevatten tijdstempels, pool, scriptbestandsnaam, verzoek-URI en de reeks functieaanroepen. Hierdoor onderscheidt het slowlog zich duidelijk van klassieke foutlogboeken, omdat het de prestaties documenteert, niet de fouten. Voor zwaar belaste sites zoals WordPress-backends levert het snel bruikbare aanwijzingen op over dure query’s, uitgebreide weergave of blokkerende I/O-bewerkingen. Wie deze momentopnames begrijpt, kan heel snel de belangrijkste oorzaak de problemen in kaart brengen en maatregelen plannen.

Zo werkt de Slowlog in het dagelijks leven

Na activering schrijft PHP-FPM een bericht wanneer een bepaalde drempel wordt overschreden Snapshot van de stack in het logboek, terwijl het verzoek doorloopt. Elk item begint doorgaans bij „#0“, dus op de plek waar op dat moment tijd verloren gaat. Tussen de blokken zie ik vaak lege regels, wat het scheiden van de gebeurtenissen vereenvoudigt. Deze methode levert steekproeven in plaats van volledige profielen, maar biedt daarentegen trefzekere aanwijzingen voor echte knelpunten, zoals omslachtige sjabloonpaden, verweesde hooks of trage netwerkverzoeken. In drukke fasen koppel ik deze aanwijzingen aan piekbelastingen en sorteer zo codefragmenten overzichtelijk. Zodra ik terugkerende patronen zie, pas ik bijvoorbeeld pm.max_kinderen en gebruik daarvoor de informatie uit pm.max_children correct instellen.

Slowlog inschakelen en configureren

Ik schakel de functie in de betreffende pool in en stel het pad, de time-out en de diepte van de trace in, zodat de Evaluatie beheersbaar blijft. Daarna start ik PHP-FPM opnieuw op en controleer ik of het logbestand beschrijfbaar is met de rechten van de poolgebruiker. Als startwaarde stel ik vaak 5 seconden in, om eerst grove uitschieters op te vangen zonder het systeem te overspoelen met loggegevens. Vervolgens verlaag ik de waarde stapsgewijs zodra de grootste problemen zijn opgelost. Voor overzichtelijke logbestanden beperk ik de trace-diepte tot 20 tot 30 frames, wat in de praktijk meestal voldoende is. Zo houd ik de Bestandsgrootte onder controle en laat geen relevante details ontgaan.

Instelling	Doel	Startwaarde	Opmerkingen
slowlog	Pad naar het logbestand	/var/log/php-fpm/www-slow.log	Controleer de paden afhankelijk van de distributie; schrijfrechten voor www-data zorgen voor
verzoek_slowlog_timeout	Drempelwaarde voor „langzaam“	5 seconden	Eerst hoog beginnen, later verlagen (bijv. 2–3 s)
request_slowlog_trace_depth	Max. diepte van het backtrace	20–30	Zorg ervoor dat traces leesbaar blijven, zonder Belangrijke informatie te verliezen

Een logbestand vinden en snel doorzoeken

Ik controleer eerst de geconfigureerde paden en open het logbestand met minder of controleer de laatste regels met tail -40. Zo zie ik meteen of er vermeldingen binnenkomen en welke scripts herhaaldelijk opvallen. Om snel een beeld te krijgen, let ik op bestandsnamen, de betrokken pools en opvallende URI’s. Als ik geen vermeldingen vind, schakel ik de opties in de pool in, laad ik de dienst opnieuw en controleer ik de eigenaar en de rechten. In beheerde omgevingen raadpleeg ik bovendien het paneel of de opstartscripts, zodat het slowlog echt meedraait.

Blokken herkennen en patronen tellen

Elk item wordt weergegeven als een blok, vaak gescheiden door een Lege regel, wat het tellen vergemakkelijkt. Ik richt me op de „#0“-regels, omdat die het huidige uitvoeringspunt aangeven waar tijd verloren gaat. Via eenvoudige shell-pijplijnen filter ik de belangrijkste functies eruit en zie ik welke punten het vaakst voor vertraging zorgen. Zo geef ik gericht prioriteit aan de functies die in totaal de meeste tijd kosten. Vervolgens controleer ik of deze hotspots alleen bij pieklasten optreden of dat ze continu problemen veroorzaken. Deze indeling bepaalt de Volgorde mijn maatregelen.

Berichten lezen: van frame #0 tot aan het begin

Bij het lezen van de berichten begin ik bovenaan bij #0 en werk ik stap voor stap naar beneden om het traject van het startpunt naar de huidige positie te begrijpen. Lange sjabloonketens duiden op een intensief renderproces, veel hooks op overbodige plug-ins en een groot aandeel SQL op ontbrekende indexen. Ik markeer regelnummers, functienamen en bestandspaden, zodat ik de code snel kan terugvinden. Als de stack eruitziet alsof er wachtrijen of herhaalde bewerkingen in zitten, controleer ik de tussenopslag en caching. Zo verlies ik geen tijd bij het Lokalisatie van het probleem in de code.

Slowlog correleren met toegangslogs

Ik koppel de Slowlog aan de webserverlogs, zodat ik de trage verzoeken van een specifieke URL kan toewijzen. Aan de hand van tijdstempels en eventueel PID’s vind ik de bijbehorende vermeldingen in het Nginx- of Apache-logboek. Zo kan ik parameters, user-agents en responstijden buiten PHP om herkennen. Als er terugkerende bezoekers of identieke query-strings opduiken, start ik een testrun met precies deze scenario’s. Zo kom ik snel tot reproduceerbare gevallen en houd ik de Analysetijd kort.

De drempelwaarde stapsgewijs verlagen

Ik begin met een ruime drempel en los eerst de grootste problemen op Uitschieters en verlaag deze vervolgens stapsgewijs. Deze werkwijze vermindert de logomvang en richt mijn energie op zinvolle aanpassingen. Na elke optimalisatieronde kies ik een lagere drempelwaarde en verzamel ik opnieuw gegevens. Zo werk ik me van de grove afstemming naar de fijnafstemming, zonder te verzanden in ruis. Het resultaat zijn doelgerichte aanpassingen en een duidelijk Overzicht van de resterende knelpunten.

Van slowlog naar oplossing: typische oplossingen

Als het Top-Frame-venster databas functies weergeeft, controleer ik de SQL-opdrachten met UITLEGGEN, voeg ontbrekende indexen toe en beperk de resultatenlijsten. Bij externe diensten verkort ik time-outs, verwerk ik antwoorden asynchroon of sla ik resultaten op in de cache. Als ik kostbare lussen tegenkom, vereenvoudig ik de logica, verminder ik het aantal doorlopen en pas ik efficiëntere structuren toe. In WordPress markeer ik terugkerende hooks, vervang ik zware uitbreidingen en kies ik voor een lichter thema. Als het aantal PHP-processen de verwerking blokkeert, houd ik de wachttijden in de gaten en lees ik aanvullend over Backtraces ook wachtrijen, bijvoorbeeld via PHP-verzoekwachtrij.

Continu gebruik: overzichtelijk logboekbeheer

Ik zet de logging niet permanent op de hoogste stand, zodat de I/O-belasting beheersbaar blijft. In plaats daarvan werk ik in fasen: actief evalueren, optimaliseren, en daarna weer terug naar een gematigd niveau. Met Logrotate houd ik bestanden compact en archiveer ik oude gegevens in gecomprimeerde vorm. Na afloop van een analyse verhoog ik de drempel of schakel ik slowlogging tijdelijk uit. Daarnaast documenteer ik bevindingen en oplossingen, zodat latere audits een duidelijk spoor aantreffen.

Hostingdiagnose: onderscheid maken tussen server en applicatie

Veel identieke Slowlog-frames bij een hoge CPU-belasting duiden op Toepassingscode, terwijl ontbrekende vermeldingen aan de serverzijde eerder wijzen op I/O-, netwerk- of databaseserverproblemen. In dergelijke gevallen vergelijk ik de TTFB, PHP-tijden en upstream-latentie om het knelpunt te lokaliseren. Als ik wachtrijen en lange wachttijden vóór de uitvoering zie, controleer ik de limieten en het aantal processen. Daarnaast vul ik mijn diagnose aan met informatie over de verwerking van verzoeken en houd ik rekening met eventuele limieten die de verwerking vertragen. Voor een gefundeerde beoordeling lees ik naast de logbestanden ook aanwijzingen over pm.max_children correct instellen of artikelen met betrekking tot wachttijden, zodat ik de Capaciteit op een zinvolle manier afstem.

Praktijkvoorbeeld: trage WordPress-backend

Ik stel verzoek_slowlog_timeout Eerst stel ik dit in op 5 seconden, start ik PHP-FPM opnieuw op en verzamel ik 30 tot 60 minuten lang gegevens onder reële belasting. Vervolgens tel ik de meest voorkomende „#0“-functies en zoek ik naar terugkerende hooks of kostbare WP_Query-aanroepen. Als er externe diensten bij betrokken zijn, meet ik de responstijden en sla ik resultaten gericht op in de cache. Als het laden van pagina’s wordt vertraagd door sessietoegangen, controleer ik het vergrendelingsgedrag en verplaats ik, indien mogelijk, sessiegerelateerde taken uit het kritieke pad. Vooral bij aanmeldingen en beheerdersacties test ik instellingen en schakel ik meldingen uit PHP sessie vergrendeling zodat mijn Backend reageert sneller.

Pool-ontwerp en rechten: een solide basis voor bruikbare slowlogs

Ik verdeel applicaties in afzonderlijke zwembaden met duidelijke namen (bijv. www, admin, api), stel unieke luisteren-aansluitingen en individuele slowlog-paden. Zo kan ik vermeldingen gemakkelijker aan elkaar koppelen en voorkom ik dat ze door elkaar raken. Consistentie is belangrijk Bestandsrechten: De pool-gebruiker (vaak www-data) heeft schrijfrechten nodig voor het logpad en de map. In container- of chroot-omgevingen controleer ik of paden in de namespace bestaan en persistent zijn – anders verdwijnen de logs bij het opnieuw opstarten.

Een Slowlog-blok in detail lezen en automatisch analyseren

Meestal beginnen de vermeldingen met een tijdstempel, pool, scriptbestandsnaam en request-URI, gevolgd door de frames. Ik tel de „#0“-regels en groepeer ze op functienaam om hotspots zichtbaar te maken. Met eenvoudige pipes haal ik de knelpunten eruit:

grep -E "^#0|request.uri|script_filename" /var/log/php-fpm/www-slow.log | sed 's/  */ /g'

Of ik som de meest voorkomende topframes op:

grep "^#0" /var/log/php-fpm/www-slow.log | awk -F": " '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -nr | head

Als ik de URL en het bestand wil opnemen, maak ik blokken aan via awk en noteer voor mij de beste combinaties van functie, URI en script. Zo stel ik prioriteiten voor de fixes die het meeste nut opleveren.

Timeout-overzicht: hoe Slowlog, PHP en de webserver samenwerken

Voor een juiste diagnose schrijf ik het volgende voor alle Time-outs: verzoek_slowlog_timeout activeert de snapshot, max_uitvoering_tijd beperkt de PHP-looptijd in het script, verzoek_terminate_timeout kan de FPM-worker geforceerd afsluiten. Op de webserver: fastcgi– of. proxy-Time-outs (bijv. fastcgi_read_timeout) en time-outs van de client. Als ik de slowlog instel boven als de server time-outs geeft, verlies ik gegevens; als hij waaronder, krijg ik nuttige momentopnames voordat de verzoeken afbreken. Daarom houd ik bewust de volgorde aan: time-out van de webserver > PHP-afsluiting > slowlog > latentie van het doel.

FPM-status, wachtrij en procesbeheer meenemen

De Slowlog laat zien dat, waarbij er tijd wordt verspild – de FPM-status laat zien dat, waarom Er zijn verzoeken in de wachtrij. Ik activeer het status-eindpunt en houd het in de gaten inactief, actief en luisterwachtrij en vergelijk deze met de Slowlog-tijdstempels. Als de wachtrij groeit terwijl veel workers vastzitten in dezelfde functies, is de code het knelpunt; als de wachtrij groeit zonder dat het Slowlog toeneemt, ontbreekt er capaciteit of remt een upstream-proces het proces af. Op basis daarvan pas ik pm-Instellingen (dynamic/ondemand), pm.max_kinderen en indien van toepassing. pm.max_aanvragen, om geheugenlekken of fragmentatie op te sporen.

Bijzonderheden in containers en beheerde omgevingen

In Docker/Kubernetes logt FPM vaak naar stdout/stderr of in paden die door logboekaggregatoren worden verzameld. Ik kies bewust voor een a Weg, zodat ik geen dubbele of ontbrekende vermeldingen heb. Met error_log = /proc/self/fd/2 en een speciale slowlog-Snapshots blijven beschikbaar op een pad dat naar een persistent volume verwijst. Bij beheerde omgevingen controleer ik of de hostingprovider slowlogs heeft ingeschakeld of beperkt – en pas ik de intervallen aan, zodat ik geen problemen krijg met rotaties.

Gegevensbescherming en veiligheid: logbestanden zonder risico

Backtraces kunnen gevoelige Parameters, die bestands paden of sessie-ID’s bevatten. Ik beperk de risico’s door query-strings in toegangslogs te vermijden, debug-uitvoer in de code uit te schakelen en de kring van personen met leesrechten klein te houden. Voor uitwisseling met derden maak ik paden anoniem en verwijder ik tokens. In productieve omgevingen stel ik korte bewaartermijnen vast en zorg ik ervoor dat logrotatie en compressie systeembreed worden toegepast.

WordPress: terugkerende patronen snel herkennen

• WP_Query/WP_Meta_Query: Ontbrekende indexen op postmeta of als er op niet-geïndexeerde velden wordt gefilterd, schiet de looptijd omhoog. Ik beperk meta-query’s, maak gebruik van taxonomieën of stel gerichte indexen in.
• Transiënten en objectcache: Veel vergelijkbare berekeningen wijzen op een gebrek aan een permanente cache. Ik schakel de objectcache in en optimaliseer de cache-sleutels en TTL's.
• Hooks/filters: Lange ketens in de stack duiden op overbodige plug-ins. Ik controleer de duurste hooks en verwijder of vervang extensies.
• HTTP-verzoeken: Interne API-aanroepen (wp_remote_get) moeten gebruikmaken van time-outs, keep-alive en caching; blokkeer de antwoorden indien mogelijk niet in de verzoekthread.
• Weergave van sjablonen: Diepte get_template_part-Cascades met bestandstoegang profiteren van caching en minder fragmentatie.

Misvattingen voorkomen: wat de Slowlog niet laat zien

De snapshot is een Momentopname. Het geeft geen beeld van de volledige levensduur van het verzoek, maar wel van de toestand op het moment dat het wordt geactiveerd. Veelvoorkomende valkuilen:

• Steekproefvertekening: Zeldzame, maar extreem dure paden kunnen verloren gaan als de time-out te kort is of de fase te kort was.
• Blokkerende systeemaanroepen: fopen, stat of DNS-lookups worden weergegeven als PHP-functies, maar de daadwerkelijke wachttijd vindt plaats in de kernel of het netwerk.
• Automatisch laden: Veel kleine includes zonder Opcache veroorzaken verspilling die in de stack onschadelijk lijkt. Een blik op de Opcache-hitrate helpt om dit in perspectief te plaatsen.

CLI, Cron en webhooks in de gaten houden

Niet alle prestatieproblemen worden via FPM afgehandeld. Zware Cronjobs (bijv. wp-cron), queue-workers of webhooks belasten de CPU, I/O of database en verslechteren zo indirect de responstijden. Ik isoleer dergelijke belasting in aparte processen, plan ze buiten piekuren in en controleer of ze via FPM-getriggerde HTTP in plaats van CLI draaien – anders verstoort dit het beeld van de slowlog.

Logrotatie in de praktijk toepassen

Om te voorkomen dat slowlogs uit de hand lopen, wissel ik ze regelmatig af en comprimeer ik oude bestanden. Een typische afwisseling houdt enkele generaties bij, geeft FPM een signaal om opnieuw te openen en voorkomt hiaten. Belangrijk: laat FPM na de rotatie opnieuw openen (HUP), zodat nieuwe vermeldingen niet in het niets verdwijnen. De concrete instellingen stem ik af op het verkeer, de time-out en de traceerdiepte.

Checklist voor snelle resultaten

• Slowlog per pool inschakelen, paden en rechten controleren.
• Begin met 5 seconden, verzamel gegevens, tel de beste frames.
• Correlatie met Access-logs: tijdstempel, URI, user-agent.
• Controleer de time-outs van de upstream- en webservers.
• De FPM-status en de wachtrij in de gaten houden, pm-Limieten aanpassen.
• Eerst de knelpunten aanpakken: SQL-indexen, caching, dure hooks, I/O.
• De time-out geleidelijk verkorten en opnieuw meten.
• Logs rouleren, bevindingen documenteren, wijzigingen bijhouden.

In het kort: jouw weg naar betere prestaties

Ik schakel de Slowlog in, lees de Topframes, vergelijk ik dit met de toegangslogs en los ik eerst de grootste uitschieters op. Daarna verlaag ik de drempelwaarde, controleer ik terugkerende patronen en pas ik gerichte aanpassingen toe in de code, de configuratie en de caching. Met logrotatie en gematigde time-outs houd ik de systeembelasting laag. Voor WordPress richt ik me op kostbare query’s, plug-ins, hooks en mogelijke sessievergrendelingen. Zo vind ik op betrouwbare wijze de echte Knelpunten en geef merkbaar snellere antwoorden.