La eliminación de la caché de NGINX coloca errores críticos de desvinculación en el registro de errores

La información de esta publicación se basa en el almacenamiento en caché FastCGI en NGINX 1.4.6 que se ejecuta en Ubuntu Server 14.04 x64. Puede ser válida o no para otras versiones.

(Actualización 2025: En el tiempo transcurrido entre que escribí la publicación original y ahora, muchas cosas han cambiado. Los servidores son más rápidos y más baratos, por lo que, de hecho, no recomendaría el enfoque descrito en esta publicación, donde trato de microadministrar la expiración de la caché solo para ahorrar algunas generaciones adicionales de contenido dinámico. Dejaré el contenido aquí para referencia futura y en caso de que alguien realmente lo necesite por alguna razón. Sin embargo, no he confirmado que esto todavía funcione para las versiones actuales de NGINX, pero creo que sí).

Después de migrar varios sitios de Apache a NGINX, me he acostumbrado mucho a sus capacidades de almacenamiento en caché integradas, que funcionan extremadamente bien en la mayoría de las circunstancias sin mucha intervención de mi parte.

Sin embargo, para uno de los sitios, realmente necesitaba la capacidad de borrar el caché (tanto por completo como eliminando entradas individuales) yo mismo. La edición gratuita de la comunidad de NGINX solo admite la caducidad del caché basada en el tiempo (es decir, puede configurarlo para verificar si algo ha cambiado después de una hora, un día, etc.). Pero, ¿qué pasa si no hay una forma confiable de determinar con anticipación cuándo cambiará un determinado recurso? Por ejemplo, no tengo idea de si pasará una hora, un día o un año antes de que vuelva y edite algo en esta publicación, ¿y por qué solo almacenar en caché durante una hora si el almacenamiento en caché durante un día hubiera estado bien?

Aquí es donde se necesita la capacidad de borrar la memoria caché manualmente (o haciendo que su aplicación web notifique a NGINX que algo debe eliminarse). Las personas detrás de NGINX son claramente conscientes de la necesidad de esto, ya que la función es compatible con la versión paga de su producto, pero si bien ciertamente tienen derecho a configurar su licencia de la forma que quieran, el precio es un poco elevado para mí cuando esta función es la única función paga que realmente necesito.

Afortunadamente, resulta que puedes eliminar archivos del directorio de caché tú mismo y NGINX lo detectará y obtendrá una nueva copia de tu back-end sin problemas. Sin embargo, si haces esto sin modificar tu configuración, es probable que veas un montón de mensajes similares a este en tu registro de errores después de un tiempo:

Parece que estos errores ocurren cuando NGINX intenta eliminar las entradas de caché después del tiempo especificado por el parámetro inactivo de la directiva fastcgi_cache_path . El valor predeterminado para esto es solo 10 minutos, pero puede configurarlo con el valor que desee. Si lo configura, por ejemplo, en 10 años, es probable que no haya reiniciado el servidor mientras tanto, por lo que el índice de clave en la memoria se habría borrado mientras tanto. Si hace esto, ¿necesita asegurarse de borrar el caché usted mismo? NGINX ya no lo hará por usted.

Me parece realmente extraño que se considere un error crítico que una entrada de caché no se pueda eliminar porque no existe. El hecho de que su clasificación de gravedad sea tan alta significa que es imposible deshacerse de él simplemente ignorando las entradas de registro por debajo de un cierto umbral. Tan pronto como se obtenga una nueva copia del back-end, la entrada volverá a existir, por lo que esto debería ser una advertencia como máximo, en mi opinión.

Ahora bien, si la entrada de caché no se pudo eliminar debido a problemas con los permisos o algo de terceros, eso sería un error crítico, porque podría hacer que NGINX continúe sirviendo contenido en caché mucho después de su tiempo de vencimiento, pero el proceso de limpieza no parece hacer esta distinción.