Implementar xCache en su aplicación PHP

No existe mucha documentación sobre el tema, sin embargo xCache es un sistema de caché de código operativo (opcode) que permite también hacer caché de variables. Esta documentación conviene principalmente para servidores Debian o Ubuntu (lo explico con Apache, pero también funciona con Lighttpd).

Antes de hacer cualquier cosa, sería bueno probar su servidor para asegurarse de como funciona ahora. Una forma simple de hacerlo es probarlo a través de ab, una herramienta de benchmarking de Apache que está incluida en el paquete de Apache. Para usarla, hay unos parámetros posibles. Recomiendo estudiar un poco la documentación, pero lo más simple (imaginando que el servidor para probar está en http://example.com/) es de lanzar:

ab -c50 -n1000 http://example.com/

Esto generará un resultado bastante amplio. Recomiendo copiarlo y guardarlo en un lugar seguro. Servirá al momento de comparar los resultados de las distintas mejoras.

xCache es super fácil de instalar en un servidor Ubuntu o Debian:

sudo apt-get install php5-xcache

sudo /etc/init.d/apache2 restart

 

Después (o antes) de relanzar el servidor web, se tiene que configurar el xCache. Esta es la parte más obscura. No hay casi nada de documentación (lo que se encuentra en el archivo de configuración mismo ya casi lo suma todo), pero básicamente no hay mucho que saber. Se edita el archivo de configuración con VIM u otro editor:

sudo vim /etc/php5/apache2/conf.d/xcache.ini

Ahí hay dos cosas principales que cambiar (potencialmente).

1. xcache.size es la cantidad de caché que su sistema permite almacenar (se puede ver con la división por 1024*1024 de: cat /proc/sys/kernel/shmmax). Será algo de 16M, 32M o 64M en muchos casos
2. xcache.count es la cantidad de procesadores que tiene esta máquina (se puede recuperar con: cat /proc/cpuinfo |grep -c processor)

De ahí es necesario recargar la configuración de Apache

sudo /etc/init.d/apache2 restart

De ahí ya sentirá probablemente una mejora, pero muy ligera.

Para probarlo, de nuevo:

ab -c50 -n1000 http://example.com

Probablemente verá una mejora (subida) en “Requests per second”.

De ahí se puede jugar un poco cambiando los parámetros de xCache como xcache.slots y xcache.size, o xcache.ttl para alcanzar mejores resultados.

Lamentablemente, estas modificaciones simples no permiten mejorar mucho la eficiencia del servidor. Pero sí se puede mejorar mucho todavía, gracias a la gestión de variables de xcache.

Para usarlo, nada más simple:

if (xcache_isset(‘un_nombre_de_variable_para_poner_en_cache’)) {

$variable = xcache_get(‘un_nombre_de_variable_para_poner_en_cache’);

} else {

$variable = query_pesado();

xcache_set(‘un_nombre_de_variable_para_poner_en_cache’,$variable);

}

 

Dicha gestión funciona para todo el sistema, es decir que la memoria usada por el proceso es compartida con otros procesos… si se tratan de varios usuarios repartidos sobre varios portales, se tiene que ser muy cuidadoso a nivel de la seguridad de la información almacenada, pero también se tiene que diseñar para que no aparezca la información de un portal en el otro.

Para esto, se puede usar, por ejemplo, un prefijo del nombre de variable con el nombre del URL del portal…

Por ejemplo, xcache_set(‘example_com_global_users_online’,$online);

No se recomienda poner ahí ninguna información personal de usuarios. Solamente datos genéricos válidos para todo un portal, y que no necesiten ser refrescados. Por ejemplo, en Chamilo mostramos siempre en la cabecera una cantidad de usuarios en línea. Pues si bien esta cantidad puede variar muy rápidamente, no importa tanto que sea la cantidad exacta, ya que a partir de 100 usuarios empieza a ser difícil saber quienes están o no están conectados.

Por lo tanto, esta información puede ser almacenada en la memoria caché compartida de xCache, y evitamos así un query bastante pesado a la base de datos para cada página refrescada o abierta: una cantidad tremenda cuando 900 usuarios simultáneos se conectan a un portal. Este pequeño cambio dió un resultado tremendo de entre 20 y 75% de respuestas adicionales por segundo en varios servidores, por lo que recomiendo altamente esta pequeña mejora.

De la misma forma, información pre-calculada del header o del footer, un marcador de la hora actual, etc, pueden fácilmente ser almacenados para todo un portal por 60 segundos: suficiente para aliviar el servidor de estas pequeñas pedidas que rápidamente suman y lo hacen más lento.

Poniendo algo de 8 variables muy pedidas en caché de esta manera, se obtiene fácilmente 20% de eficiencia adicional, según el Apache Benchmark.

ab -c50 -n1000 http://example.com

Para finalizar, si usted está desarrollando un sistema para grande distribución (por ejemplo una plataforma de software libre), debería pensar bien en los casos de uso posibles, entre otros el alojamiento de varios portales con URLs distintos en un mismo servidor (usar prefijo como arriba) y el uso dentro de muchos scripts y contextos distintos (otro prefijo, puede ser).