Feil 504 i WordPress: webhotellet eller nettstedet

#Hva betyr feil 504 i WordPress?

MDN, med henvisning til RFC 9110, definerer 504 som en situasjon der en server som fungerer som gateway eller proxy “did not get a response in time from the upstream server”. Det er noe annet enn 502 Bad Gateway: der kom det et svar, men det var ugyldig. Ved 504 kom det ingenting.

På et typisk WordPress-webhotell ser kjeden slik ut: nettleser, eventuelt et CDN, nginx, PHP-FPM, databasen og eventuelt en objektcache. Koden 504 genereres av leddet som ventet. Det alene forteller hvor du skal lete. Hvis nginx venter på PHP, ligger problemet i PHP, databasen eller køen til PHP. Hvis CDN-et venter, ligger problemet på opprinnelsesserveren.

MDN-dokumentasjonen påpeker også at det finnes mange mulige årsaker, og at utbedringen vanligvis krever analyse fra serveradministratorens side. Derfor finnes det her ingen magisk rettelse, bare en rekkefølge på kontrollene.

#Er 504 webhotellets skyld eller nettstedets?

Spørsmålet avgjøres av hvor omfattende feilen er. Tabellen under er en beslutningssnarvei, ikke en dom.

Webhotellets ansvar begynner der grensene (antall workere, minne, CPU) er for små for nettstedets normale trafikk. Nettstedets ansvar begynner der én enkelt forespørsel gjør så mye arbeid at den blokkerer en worker i flere titalls sekunder. I praksis er det ofte begge deler samtidig: trege forespørsler opptar workerne, og en liten pool har ingen reserve.

#Hvordan finner du ut hvor forespørselen satt fast?

Start med tre steder, i denne rekkefølgen.

1. Feilloggen til webserveren fra tidspunktet for feilen. I nginx bekrefter oppføringen upstream timed out at serveren ventet på PHP.
2. PHP-FPM-loggen. Meldingen om at pm.max_children er nådd betyr at poolen var full og at de neste forespørslene sto i kø. Alternativet pm.max_children setter, slik PHP-dokumentasjonen beskriver det, grensen for samtidige forespørsler som poolen behandler.
3. WordPress-loggen. Sett WP_DEBUG til true, WP_DEBUG_LOG til true og WP_DEBUG_DISPLAY til false i wp-config.php. Feilene havner da i wp-content/debug.log i stedet for på skjermen. Slik beskriver WordPress-dokumentasjonen det. Slå av debug etter diagnosen.

Hvis webhotellet gir tilgang til PHP-FPM-slowloggen, sett request_slowlog_timeout, så skriver PHP en backtrace for forespørsler som varer lenger enn grensen. Alternativet er som standard slått av (verdien 0). Backtracen viser i hvilken funksjon i en plugin eller et tema PHP ventet.

På delt webhotell har du ofte ikke tilgang til disse loggene. Da er tilgang til dem og til målingene for PHP-poolen det første du må be supporten om, sammen med tidspunktet for feilen og adressen som returnerte 504.

#Hvorfor gir en for liten PHP-FPM-pool 504?

Hver dynamiske forespørsel opptar én PHP-FPM-worker til svaret er ferdig. Når alle workerne er opptatt, må nye forespørsler vente. Hvis de venter lenger enn proxyens grense, ser den besøkende 504.

Standard fastcgi_read_timeout i nginx er 60 sekunder, og nginx-dokumentasjonen påpeker at grensen måles mellom to påfølgende lesinger fra FastCGI-serveren, ikke for hele svaret. På administrerte webhotell kan verdien være en annen, så ikke anta at den hos deg er akkurat 60 sekunder.

Å øke pm.max_children hjelper bare hvis serveren har minne til det. Hver WordPress-worker med noen få plugins tar en merkbar del av det, så en for høy verdi ender i tomt for RAM og drepte prosesser, altså en verre tilstand enn en kø. Konfigurasjon av poolen er en jobb for administratoren, som kan se minnebruken.

#Hvordan gir trege spørringer og autoloadede alternativer 504?

Når 504 gjelder hele nettstedet og poolen ikke er full på grunn av trafikk, sjekk databasen. WordPress-dokumentasjonen peker på at WordPress gjentar mange spørringer i hver forespørsel, og at alternativer markert som autoload lastes ved hvert besøk. Den anbefaler å holde dem under 800 KB, og de fullstendige anbefalingene står i optimaliseringsveiledningen. En plugin som lagrer store datamengder i wp_options med autoload, presser dem inn i hver forespørsel. Størrelsen på autoloaden kan du sjekke med en SQL-spørring på kolonnen autoload i alternativtabellen.

For å finne trege spørringer finnes konstanten SAVEQUERIES. Den lagrer hver spørring, kjøretiden og funksjonen som kalte den, i $wpdb->queries. Den koster ytelse, så slå den på kort tid og helst på staging.

#Når gir objektcache og Redis 504?

En vedvarende objektcache reduserer antall spørringer mot databasen og gjør vanligvis nettstedet raskere. Den krever likevel en fungerende cacheserver og drop-in-filen wp-content/object-cache.php.

Feilen slår motsatt vei når filen finnes og Redis-serveren ikke svarer. Hver forespørsel prøver da å koble seg til cachen, venter på tilkoblings-timeouten og går først deretter videre eller gir opp. Symptomet er 504 rett etter en omstart eller et sammenbrudd i cachetjenesten hos webhotellet, selv om koden i nettstedet ikke er endret.

Testen er enkel: gi object-cache.php et annet navn. Hvis 504 forsvinner, er det cachen som er synderen, ikke WordPress. Sett filen tilbake først etter at tjenesten er reparert.

#Hvordan gir WP-Cron, admin-ajax og eksterne API-er 504?

Tre kilder til enkeltstående, trege forespørsler bør sjekkes hver for seg.

• WP-Cron. WordPress-dokumentasjonen forklarer at WP-Cron kjøres når noen besøker nettstedet, ikke som en fast prosess. Forsinkede, tunge oppgaver (sikkerhetskopier, import, utsendelse) kan derfor belaste en vanlig besøkendes forespørsel. Å flytte kallene til webhotellets system-cron avlaster fronten.
• admin-ajax.php. Plugins sender forespørsler hit fra administrasjonspanelet og fra fronten. Hvis 504 vises akkurat her, let etter en plugin som gjør en tung operasjon i bakgrunnen.
• Eksterne API-er. En plugin som venter på et tregt eksternt system (betaling, ERP, utsendelse) holder en worker så lenge systemet bruker på å svare. Uten en egen, kort timeout i den pluginen blir andres driftsstans til ditt 504.

#Hva er forskjellen på 504, 502 og 524?

• 502 Bad Gateway: serveren bak proxyen svarte, men svaret var ugyldig. Ofte en krasjet PHP-FPM-prosess.
• 504 Gateway Timeout: ikke noe svar i tide. Oftest overbelastning eller en treg forespørsel.
• 524: en Cloudflare-kode. Cloudflare-dokumentasjonen oppgir at den vises når opprinnelsesserveren ikke svarer innen standardgrensen på 125 sekunder. Cloudflare anbefaler å be webhotellet sjekke lange prosesser og overbelastning, og å flytte store operasjoner over på en kanal uten proxy.

Bak et CDN kan du derfor se to ulike koder for samme årsak, avhengig av hvilket ledd som mistet tålmodigheten først.

#Når bør du øke timeouten, og når ikke?

Å øke fastcgi_read_timeout eller PHP-tidsgrensen er begrunnet for én bevisst lang operasjon, for eksempel en manuell import. For et nettsted som viser 504 til besøkende er det en tilsløring: den trege forespørselen opptar fortsatt en worker, bare lenger, og poolen fylles raskere.

PHP-FPM har en egen sikring, request_terminate_timeout. Dokumentasjonen beskriver den som en grense der prosessen som behandler forespørselen blir drept, og oppgir standardverdien 0, altså avslått. Når den er satt fornuftig, beskytter den poolen mot ett enkelt hengende skript.

#Hvordan utbedrer du 504 trinn for trinn?

1. Avgrens feilen: hele nettstedet, én adresse eller bare wp-admin.
2. Les server- og PHP-FPM-loggene fra tidspunktet for feilen.
3. Slå på debug.log og gjenskap feilen.
4. Slå av pluginene (via WP-CLI eller ved å gi katalogen nytt navn), og slå dem på igjen én og én mens du måler responstiden.
5. Hvis object-cache.php finnes, slå den av som test.
6. Sjekk de autoloadede alternativene og forsinkede WP-Cron-oppgaver.
7. Vurder først til slutt å øke poolen eller timeoutene, sammen med webhotellets administrator.

Hvis 504 dukket opp rett etter en oppdatering, ta også en titt på veiledningen om gjenoppretting av WordPress etter en mislykket oppdatering.

#Når er dette en jobb for en spesialist?

Når loggene peker mot PHP-FPM-poolen, men webhotellet ikke gir tilgang til konfigurasjonen. Når 504 kommer tilbake etter hver utbedring. Når nettbutikken mister bestillinger mens feilen varer. Ved en gjennomgang som skal skille kostnaden for webhotellet fra kostnaden for koden, hjelper optimalisering av ytelsen på WordPress-nettstedet. Når nettstedet ligger nede nå og årsaken er ukjent, er WordPress-reparasjon og teknisk support redningen.