Sletning af NGINX-cache sætter kritiske unlink-fejl i fejllog

Oplysningerne i dette indlæg er baseret på FastCGI-caching på NGINX 1.4.6, der kører på Ubuntu Server 14.04 x64. Det er muligvis ikke gyldigt for andre versioner.

(Opdatering 2025: I tiden mellem jeg skrev det originale indlæg og nu, har meget ændret sig. Servere er hurtigere og billigere, så jeg vil faktisk ikke anbefale den fremgangsmåde, der er beskrevet i dette indlæg, hvor jeg forsøger at mikroadministrere cacheudløb bare for at gemme et par ekstra generationer af dynamisk indhold. Jeg vil efterlade indholdet her til fremtidig reference, og hvis nogen rent faktisk har brug for det, uanset hvilken grund det er bekræftet af, INNG. dog, men det vil jeg tro, at det gør).

Efter at have migreret adskillige websteder fra Apache til NGINX er jeg blevet meget glad for dens indbyggede caching-funktioner, som fungerer ekstremt godt under de fleste omstændigheder uden megen indblanding fra mig.

Men for et af webstederne havde jeg virkelig brug for muligheden for selv at rydde cachen (både fuldt ud og fjerne individuelle poster). Den gratis community-udgave af NGINX understøtter kun tidsbaseret cache-udløb (dvs. du kan indstille den til at tjekke, om noget er ændret efter en time, en dag osv.). Men hvad hvis der ikke er nogen pålidelig måde at bestemme på forhånd, hvornår en bestemt ressource vil ændre sig? Jeg aner for eksempel ikke, om der går en time, en dag eller et år, før jeg vender tilbage og redigerer noget i dette indlæg – og hvorfor kun cache i en time, hvis cache for en dag ville have været fint?

Det er her, der er behov for muligheden for at rydde cachen manuelt (eller ved at få din webapplikation til at underrette NGINX om, at noget skal renses). Folkene bag NGINX er tydeligvis klar over behovet for dette, da funktionen er understøttet i den betalte version af deres produkt – men selvom de bestemt er berettiget til at opsætte deres licenser, som de vil, er prisen lidt stejl for mig, når denne funktion er den eneste betalte funktion, jeg virkelig har brug for.

Heldigvis viser det sig, at du bare selv kan slette filer fra cache-mappen, og NGINX vil opfange dette og hente en ny kopi fra din back-end uden problemer. Men hvis du gør dette uden at justere din konfiguration, vil du sandsynligvis se en hel masse meddelelser, der ligner denne i din fejllog efter et stykke tid:

Det ser ud til, at disse fejl opstår, når NGINX selv forsøger at slette cacheposter efter den tid, der er angivet af den inaktive parameter i fastcgi_cache_path- direktivet. Standarden for dette er kun 10 minutter, men du kan indstille den til den værdi, du ønsker. Hvis du indstiller det til f.eks. 10 år, er det sandsynligvis usandsynligt, at du ikke har genstartet serveren i mellemtiden, så nøgleindekset i hukommelsen ville være blevet ryddet i mellemtiden. Hvis du gør dette, skal du sørge for at rydde cachen selv, NGINX vil ikke længere gøre det for dig.

Jeg synes, det er virkelig mærkeligt, at det betragtes som en kritisk fejl, at en cache-indgang ikke kan slettes, fordi den ikke eksisterer. Det faktum, at dens alvorlighedsklassificering er så høj, betyder, at den er umulig at slippe af med bare ved at ignorere logindtastninger under en vis tærskel. Så snart en ny kopi er hentet fra back-end, vil posten eksistere igen, så dette burde højst være en advarsel efter min mening.

Nu, hvis cache-indgangen ikke kunne slettes på grund af problemer med tilladelser eller noget tredje, ville det være en kritisk fejl, fordi det kan få NGINX til at fortsætte med at levere cachelagret indhold længe efter dets udløbstid, men oprydningsprocessen ser ikke ud til at skelne.