Að eyða NGINX skyndiminni setur mikilvægar aftengingarvillur í villuskrá

Upplýsingarnar í þessari færslu eru byggðar á FastCGI-caching í NGINX 1.4.6 sem keyrir á Ubuntu Server 14.04 x64. Það getur verið að þetta gildi ekki fyrir aðrar útgáfur.

(Uppfærsla 2025: Á þeim tíma sem ég skrifaði upprunalega færsluna og núna, hefur margt breyst. Vefþjónarnir eru hraðari og ódýrari, þannig að ég myndi í raun ekki mæla með þeirri aðferð sem lýst er í þessari færslu þar sem ég reyni að stjórna útrunnu fyrningartímum gæslunnar til að spara aðeins nokkrar kynslóðir af dynamískum efni. Ég skil eftir efnið hér fyrir framtíðarviðmið og ef einhver raunverulega þarf það af einhverjum ástæðum. Ég hef ekki staðfest að þetta virki enn fyrir núverandi útgáfur af NGINX, en ég myndi halda að það geri það).

Þegar ég flutti margar síður frá Apache til NGINX hef ég orðið mjög hrifinn af innbyggðum cache-möguleikum þess, sem virka ótrúlega vel undir flestum kringumstæðum án mikillar íhlutunar frá mér.

Hins vegar, fyrir eina af síðunum, þurfti ég virkilega getu til að hreinsa cache-ið (bæði alveg og fjarlægja einstaka færslur) sjálfur. Ókeypis samfélagsútgáfa NGINX styður aðeins tíma-bundna útrunnu fyrningu cache (þ.e. þú getur stillt það til að athuga hvort eitthvað hafi breyst eftir klukkutíma, dag, o.s.frv.). En hvað ef það er engin áreiðanleg leið til að ákvarða fyrirfram hvenær ákveðin auðlind mun breytast? Til dæmis, ég hef enga hugmynd um hvort það verði klukkutími, dagur eða ár áður en ég fer aftur og breyti einhverju í þessari færslu – og af hverju bara að geyma í cache í eina klukkustund ef geymsla í eina dag væri í lagi?

Þetta er þar sem þörf er á getu til að hreinsa cache-ið handvirkt (eða með því að láta vefumsóknina tilkynna NGINX að eitthvað ætti að hreinsa). Fólkið á bak við NGINX er augljóslega meðvitað um þörfina fyrir þetta þar sem þessi eiginleiki er studdur í borguðu útgáfu vöru þeirra – en þó þeir séu vissulega heimilt að stilla leyfisveitingar sínar hvernig sem er, þá er verðið örlítið hátt fyrir mig þegar þessi virkni er eina borgaða eiginleikinn sem ég þarf raunverulega.

Heppnilega kemur í ljós að þú getur bara eytt skrám úr cache-möppunni sjálfur og NGINX mun taka eftir þessu og sækja nýja útgáfu frá bakendinu án vandræða. Hins vegar, ef þú gerir þetta án þess að breyta stillingum þínum, þá muntu líklega sjá mikið af skilaboðum sem líkjast þessum í villuloggi þínum eftir smá tíma:

Það virðist sem þessar villur komi upp þegar NGINX sjálft reynir að eyða cache-færslum eftir tímann sem tilgreindur er með inactive breytunni í fastcgi_cache_path fyrirmælinu. Sjálfgefið fyrir þetta er aðeins 10 mínútur, en þú getur stillt það á hvaða gildi sem er. Ef þú stillir það, segjum, á 10 ár, þá er það líklega ólíklegt að þú hafir ekki endurræst þjóninn á meðan, svo lykilvísitölurnar í minni hafa líklega verið hreinsaðar á meðan. Ef þú gerir þetta, þarftu að ganga útfyllilega úr því að hreinsa cache-ið sjálfur, NGINX mun ekki lengur gera það fyrir þig.

Ég finn það mjög furðulegt að það sé talið alvarlegt vandamál að cache-færsla geti ekki verið eytt vegna þess að hún er ekki til. Það að alvarleikastig þess sé svo hátt þýðir að það er ómögulegt að losna við það bara með því að hunsa logg færslur undir ákveðnu þröskuldi. Þegar ný útgáfa er sótt frá bakendinu mun færslan verða til aftur, svo þetta ætti að vera viðvörun að hámarki, að mínu mati.

Nú, ef cache-færsla gat ekki verið eytt vegna vandamála með leyfi eða eitthvað þriðja, það væri alvarlegt vandamál, vegna þess að það gæti gert það að NGINX haldi áfram að afhenda cache-að efni langa tíma eftir að það hefur útrunnið, en hreinsunarferlið virðist ekki gera þessa greinarmun.