L'eliminazione della cache NGINX inserisce errori critici di scollegamento nel registro degli errori

Le informazioni in questo post si basano sulla memorizzazione nella cache FastCGI su NGINX 1.4.6 in esecuzione su Ubuntu Server 14.04 x64. Potrebbero essere valide o meno per altre versioni.

(Aggiornamento 2025: nel periodo trascorso tra la stesura del post originale e oggi, molto è cambiato. I server sono più veloci ed economici, quindi in effetti non consiglierei l'approccio descritto in questo post in cui provo a microgestire la scadenza della cache solo per salvare qualche generazione extra di contenuto dinamico. Lascerò il contenuto qui per riferimento futuro e nel caso in cui qualcuno ne abbia effettivamente bisogno per qualsiasi motivo. Non ho confermato che questo funzioni ancora per le versioni correnti di NGINX, però, ma penso di sì).

Dopo aver migrato diversi siti da Apache a NGINX, ho iniziato ad apprezzare molto le sue funzionalità di caching integrate, che funzionano estremamente bene nella maggior parte delle circostanze senza troppi interventi da parte mia.

Tuttavia, per uno dei siti, avevo davvero bisogno della possibilità di cancellare la cache (sia completamente che rimuovendo singole voci) da solo. L'edizione gratuita della community di NGINX supporta solo la scadenza della cache basata sul tempo (ad esempio, puoi impostarla per controllare se qualcosa è cambiato dopo un'ora, un giorno, ecc.). Ma cosa succede se non c'è un modo affidabile per determinare in anticipo quando cambierà una certa risorsa? Ad esempio, non ho idea se passerà un'ora, un giorno o un anno prima che io torni e modifichi qualcosa in questo post, e perché mettere in cache solo per un'ora se la memorizzazione nella cache per un giorno sarebbe andata bene?

Ecco dove è necessaria la possibilità di cancellare manualmente la cache (o facendo in modo che la tua applicazione web notifichi a NGINX che qualcosa deve essere eliminato). Le persone dietro NGINX sono chiaramente consapevoli della necessità di questo, poiché la funzionalità è supportata nella versione a pagamento del loro prodotto, ma mentre hanno certamente il diritto di impostare la loro licenza come vogliono, il prezzo è un po' alto per me, dato che questa funzione è l'unica funzionalità a pagamento di cui ho realmente bisogno.

Fortunatamente, si scopre che puoi semplicemente eliminare i file dalla directory della cache e NGINX se ne accorgerà e recupererà una nuova copia dal tuo back-end senza intoppi. Tuttavia, se lo fai senza modificare la tua configurazione, è probabile che dopo un po' vedrai un sacco di messaggi simili a questo nel tuo registro degli errori:

Sembra che questi errori si verifichino quando NGINX stesso tenta di eliminare voci della cache dopo il tempo specificato dal parametro inactive della direttiva fastcgi_cache_path . Il valore predefinito è di soli 10 minuti, ma puoi impostarlo su qualsiasi valore tu voglia. Se lo imposti, ad esempio, su 10 anni, è probabilmente improbabile che tu non abbia riavviato il server nel frattempo, quindi l'indice della chiave in memoria sarebbe stato cancellato nel frattempo. Se lo fai, devi assicurarti di cancellare la cache da solo, NGINX non lo farà più per te.

Trovo davvero strano che sia considerato un errore critico il fatto che una voce di cache non possa essere eliminata perché non esiste. Il fatto che la sua classificazione di gravità sia così alta significa che è impossibile liberarsene semplicemente ignorando le voci di log al di sotto di una certa soglia. Non appena una nuova copia viene recuperata dal back-end, la voce esisterà di nuovo, quindi questo dovrebbe essere al massimo un avviso, secondo me.

Ora, se la voce della cache non potesse essere eliminata a causa di problemi con i permessi o per qualcos'altro, si tratterebbe di un errore critico, perché potrebbe far sì che NGINX continui a fornire contenuti memorizzati nella cache molto tempo dopo la sua scadenza, ma il processo di pulizia non sembra fare questa distinzione.