Ang pagtanggal ng NGINX Cache ay Naglalagay ng Mga Kritikal na Error sa Pag-unlink sa Error Log

Ang impormasyon sa post na ito ay batay sa FastCGI caching sa NGINX 1.4.6 na tumatakbo sa Ubuntu Server 14.04 x64. Maaaring tama o hindi ito para sa ibang mga bersyon.

(Update 2025: Sa pagitan ng pagsulat ko ng orihinal na post na ito at ngayon, marami na ang nagbago. Mas mabilis at mas mura na ang mga server, kaya't hindi ko na inirerekomenda ang paraan na inilarawan sa post na ito kung saan sinubukan kong pamahalaan ang expiration ng cache upang makatipid ng ilang extra na henerasyon ng dynamic content. Iiwan ko na lamang ang nilalaman dito para sa mga susunod na reference at kung sakaling may mangailangan nito sa anumang dahilan. Hindi ko pa nakumpirma kung gumagana pa ito para sa mga kasalukuyang bersyon ng NGINX, pero sa tingin ko ay oo.)

Matapos mag-migrate ng ilang mga site mula Apache patungong NGINX, natutunan kong magustuhan ang mga kakayahan ng built-in na caching nito, na talagang gumagana ng maayos sa karamihan ng mga sitwasyon nang hindi ako masyadong nakikialam.

Gayunpaman, para sa isa sa mga site, talagang kailangan ko ng kakayahan na linisin ang cache (buo o alisin ang mga indibidwal na entry) ako mismo. Ang libreng community edition ng NGINX ay sumusuporta lamang sa time-based cache expiry (i.e. maaari mong itakda ito upang tingnan kung may nagbago pagkatapos ng isang oras, isang araw, atbp.). Ngunit paano kung walang maaasahang paraan upang matukoy nang maaga kung kailan magbabago ang isang partikular na resource? Halimbawa, wala akong ideya kung isang oras, isang araw, o isang taon bago ko balikan at i-edit ang isang bagay sa post na ito – at bakit pa limitahan ang cache sa isang oras kung caching para sa isang araw ay sapat na?

Dito kinakailangan ang kakayahan na manu-manong linisin ang cache (o sa pamamagitan ng pagpapabatid ng iyong web application sa NGINX na may dapat alisin). Malinaw na batid ng mga tao sa likod ng NGINX ang pangangailangan para dito dahil ang tampok na ito ay sinusuportahan sa bayad na bersyon ng kanilang produkto – ngunit bagamat may karapatan sila na itakda ang kanilang lisensya sa anumang paraan na gusto nila, medyo mataas ang presyo para sa akin kapag ang function na ito lang ang tanging bayad na tampok na talagang kailangan ko.

Sa kabutihang palad, lumalabas na maaari mong burahin ang mga file mula sa cache directory nang ikaw mismo at kukunin ng NGINX ang bagong kopya mula sa iyong back-end nang walang aberya. Gayunpaman, kung gagawin mo ito nang hindi inaayos ang iyong configuration, malamang na makakita ka ng maraming mensahe na katulad nito sa iyong error log matapos ang ilang panahon:

Ang mga error na ito ay lumilitaw kapag ang NGINX mismo ay sinusubukang burahin ang mga entry ng cache pagkatapos ng oras na tinukoy ng inactive parameter ng fastcgi_cache_path na direktiba. Ang default nito ay 10 minuto lamang, ngunit maaari mo itong itakda sa anumang halaga na gusto mo. Kung itatakda mo ito, halimbawa, sa 10 taon, malamang na hindi mo pa na-restart ang server sa panahong iyon kaya't ang key index sa memorya ay malamang na na-clear na. Kung gagawin mo ito, kailangan mong siguraduhin na ikaw mismo ang maglilinis ng cache, hindi na ito gagawin ng NGINX para sa iyo.

Talaga akong nagtaka na itinuturing itong isang kritikal na error na hindi ma-delete ang isang cache entry dahil hindi ito umiiral. Ang katotohanan na ang klasipikasyon ng kalubhaan nito ay napakataas ay nangangahulugang hindi ito mawawala sa pamamagitan lamang ng pag-ignore sa mga log entries sa ibaba ng isang partikular na threshold. Kapag kinuha na ang bagong kopya mula sa back-end, muling magiging umiiral ang entry, kaya't sa aking opinyon, dapat itong ituring na isang warning lang.

Ngayon, kung ang cache entry ay hindi natanggal dahil sa mga problema sa permissions o ibang bagay, iyon ay isang kritikal na error, dahil maaaring magpatuloy ang NGINX sa pagserbisyo ng cached content kahit tapos na ang expiry time nito, ngunit hindi mukhang ginagawa ng proseso ng paglilinis ang pagkakaibang ito.