Sletting av NGINX-buffer setter kritiske frakoblingsfeil i feilloggen

Informasjonen i dette innlegget er basert på FastCGI-bufring på NGINX 1.4.6 som kjører på Ubuntu Server 14.04 x64. Det kan være eller ikke være gyldig for andre versjoner.

(Oppdatering 2025: I tiden mellom jeg skrev det opprinnelige innlegget og nå, har mye endret seg. Servere er raskere og billigere, så jeg vil faktisk ikke anbefale tilnærmingen som er beskrevet i dette innlegget der jeg prøver å mikroadministrere cache-utløpet bare for å lagre noen ekstra generasjoner med dynamisk innhold. Jeg vil la innholdet være her for fremtidig referanse, og i tilfelle noen faktisk trenger det av en hvilken som helst versjon av den nåværende versjonen, INNG. skjønt, men jeg vil tro at det gjør det).

Etter å ha migrert flere nettsteder fra Apache til NGINX har jeg blitt veldig glad i dens innebygde caching-funksjoner, som fungerer ekstremt bra under de fleste omstendigheter uten mye innblanding fra meg.

Men for et av nettstedene trengte jeg virkelig muligheten til å tømme hurtigbufferen (både fullstendig og fjerne individuelle oppføringer) selv. Den gratis fellesskapsutgaven av NGINX støtter kun tidsbasert cache-utløp (dvs. du kan sette den opp for å sjekke om noe har endret seg etter en time, en dag osv.). Men hva om det ikke er noen pålitelig måte å avgjøre på forhånd når en viss ressurs vil endre seg? Jeg aner for eksempel ikke om det tar en time, en dag eller et år før jeg kommer tilbake og redigerer noe i dette innlegget – og hvorfor bare cache i en time hvis caching for en dag hadde vært greit?

Det er her muligheten til å tømme hurtigbufferen manuelt (eller ved å få nettapplikasjonen din til å varsle NGINX om at noe bør renses). Folkene bak NGINX er tydelig klar over behovet for dette ettersom funksjonen støttes i den betalte versjonen av produktet deres – men selv om de absolutt har rett til å sette opp lisensieringen slik de vil, er prisen litt høy for meg når denne funksjonen er den eneste betalte funksjonen jeg virkelig trenger.

Heldigvis viser det seg at du bare kan slette filer fra cache-katalogen selv, og NGINX vil plukke opp dette og hente en ny kopi fra back-end uten problemer. Men hvis du gjør dette uten å justere konfigurasjonen din, vil du sannsynligvis se en hel haug med meldinger som ligner på denne i feilloggen din etter en stund:

Det ser ut til at disse feilene oppstår når NGINX selv prøver å slette cache-oppføringer etter tiden spesifisert av den inaktive parameteren i fastcgi_cache_path -direktivet. Standard for dette er bare 10 minutter, men du kan sette den til hvilken verdi du vil. Hvis du setter den til for eksempel 10 år, er det sannsynligvis usannsynlig at du ikke har startet serveren på nytt i mellomtiden, slik at nøkkelindeksen i minnet ville blitt slettet i mellomtiden. Hvis du gjør dette, må du sørge for at du tømmer hurtigbufferen selv, NGINX vil ikke lenger gjøre det for deg.

Jeg synes det er veldig merkelig at det anses som en kritisk feil at en cache-oppføring ikke kan slettes fordi den ikke eksisterer. Det faktum at alvorlighetsklassifiseringen er så høy betyr at den er umulig å bli kvitt bare ved å ignorere loggoppføringer under en viss terskel. Så snart en ny kopi er hentet fra back-end, vil oppføringen eksistere igjen, så dette bør være en advarsel på det meste, etter min mening.

Nå, hvis hurtigbufferoppføringen ikke kunne slettes på grunn av problemer med tillatelser eller noe tredje, ville det være en kritisk feil, fordi det kan få NGINX til å fortsette å levere bufret innhold lenge etter utløpstiden, men oppryddingsprosessen ser ikke ut til å gjøre denne forskjellen.