Usar nginx como proxy cache con WordPress
Podemos usar nginx como un proxy cache para almacenar el HTML resultante de las peticiones. En este caso veremos como usarlo con ficheros en disco.
Primero de todo deberemos crear un directorio dónde almacenar los ficheros de la caché y asignar los permisos que sean necesarios, en este caso el usuario nginx:
mkdir -p /var/www/cache/systemadmin.es chown nginx. /var/www/cache/systemadmin.es
A continuación en el bloque http deberemos definir el path de dicha caché y algunas opciones:
- Primer parámetro: El path a usar, deberíamos usar preferiblemente un disco local
- Segundo parámetro (opcional) con levels: Número de niveles y con que carácteres organizar la caché. Por ejemplo 1:2 indicamos que el primer nivel sería el último carácter del fichero y el segundo nivel los dos siguientes.
- Tercer parámetro con keys_zone: Indicamos el nombre de la caché y el tamaño de la shared memory para las keys (relación entre petición y fichero de la caché)
- Cuarto parámetro (opcional) con inactive: Indicamos por cuanto tiempo mantenemos una clave en la caché si no se vuelve a pedir el mismo contenido
- Quinto parámetro con max_size: Indicamos el tamaño máximo de la caché
Por ejemplo, podemos definir una caché como la siguiente:
proxy_cache_path /var/www/cache/systemadmin.es levels=1:2 keys_zone=cache_systemadmin:10m;
A continuación dentro del bloque server que queramos añadir la caché deberemos añadir las siguientes directivas:
- proxy_cache: Indicamos la caché a usar, mediante la directiva proxy_cache_path del bloque http podemos definir más de una.
- proxy_cache_key: Definimos la clave a usar las variables que consideremos oportunas. Por ejemplo para:
$scheme$proxy_host$request_uri$is_args$args
La key quedaría como la siguiente:
KEY: http10.10.10.10:8181/2010/08/videochat-en-gtalk-para-fedora-centos-y-rhel
- proxy_cache_valid: Mediante esta directiva indicamos los tiempos según la respuesta. Por ejemplo para cachear durante 20 minutos las respuestas HTTP 200 haríamos:
proxy_cache_valid 200 20m;
Las directivas podrían quedar como las siguientes:
proxy_cache cache_systemadmin; proxy_cache_key $scheme$host$proxy_host$request_uri$is_args$args; proxy_cache_valid 200 10m; proxy_cache_valid 301 1h; proxy_cache_valid any 1m;
Además, para evitar que cuando caduque el contenido existan varios theads intentando actualizar el contenido podemos usar la directiva proxy_cache_use_stale updating. Con esta directiva se crea un único thread que actualiza el contenido mientras que el resto sirven el contenido caducado mientras no este actualizado. La directiva la deberemos añadir al bloque server:
proxy_cache_use_stale updating;
En el directorio de la caché encontraremos la estructura que hemos definido con ficheros
# find . -type f ./d/84/68f89a27a13cd26a8b0b294a57ec584d ./b/80/4814c82189539fe3ad3f7b231f35b80b ./b/92/47b1b5f9b2a66b8b89c82d28fe61a92b ./4/62/1368a1d017d6d9d6c6a146fa407d4624 ./8/3d/9b4fdf2a08f03ece04742298f4cc13d8
El fichero se llama como el md5 de la key, por ejemplo:
$ echo -n "http10.10.10.10:8181/2010/08/videochat-en-gtalk-para-fedora-centos-y-rhel" | md5sum 375458a497e488e19e09ff273a9ac7d3 -
En el fichero 375458a497e488e19e09ff273a9ac7d3 podremos ver el resultado de la petición al backend:
(...) KEY: http10.10.10.10:8181/2010/08/videochat-en-gtalk-para-fedora-centos-y-rhel HTTP/1.0 200 OK Date: Mon, 21 Nov 2011 21:21:45 GMT Server: nginx X-Pingback: http://systemadmin.es/xmlrpc.php Connection: close Content-Type: text/html; charset=UTF-8 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> (...)
Dichas opciones las he probado con un WordPress y parece que se gestiona bien de por si el contenido cacheable y el que no (por ejemplo, si hay un usuario logado o la parte de administración) ya que la aplicación incluye el header Cache-Control para señalar que contenido es cacheable y cual no:
Cache-Control: no-cache, must-revalidate, max-age=0
Pero en inconveniente evidente sigue existiendo: Si modificamos algún contenido no será visible mientras no caduque la caché ya que no estamos notificando de ninguna forma desde la aplicación a la cache que se debe actualizar.
Actualización: Para poder escribir comentarios directamente en los posts estando logado al WordPress deberemos añadir la cookie a la key a utilizar mediante una variable:
if ($http_cookie ~* "wordpress_logged_in_[^=]*=([^%]+)%7C")
{
set $cookie_wordpress $1;
}
Por lo que la proxy_cache_key quedaría:
proxy_cache_key $scheme$host$proxy_host$uri$is_args$args$cookie_wordpress;
Relacionados
Imprimir
Deja un comentario: