PHPBSD.net » cache

Cache de páginas estáticas para PHP

Oriol — Wed, 16 May 2007 01:31:45 +0000

El motor de PHP es uno de los más rápidos generando páginas web aún así nunca será tan rápido como no tener que generar nada y que el servidor web devuelva páginas estáticas. A pesar de disponer de una aplicación web escrita en PHP podemos conseguir la misma velocidad que en una web estática cacheando las páginas generadas. Lo que se porpone a continuación es un sistema de cache donde las páginas sólo se generarán la primera vez que se acceda a ellas, en siguientes peticiones el servidor web devolverá las páginas estáticas generadas.

Existen varias propuestas de sistemas de cache donde siempre se ejecuta un script PHP trabajando con el output-buffer para guardar la respuesta. Estos sistemas de cache tiene el inconveniente de que a pesar de tener la página cacheada siempre estamos ejecutando un script PHP con el coste en rendimiento que ello conlleva. Como solución se propone trabajar con el output-buffer pero usar la directiva de configuración ErrorDocument del Apache para que si ya tenemos la página generada no se ejecute ni un script PHP.

La directiva ErrorDocument se usa para configurar lo que el servidor devolverá al cliente en caso de error. Pues bien, se trata de configurar el error que indica que no existe la página solicitada (error 404) para que apunte a un script PHP donde generaremos la página. En la siguiente petición a la misma página el Apache devolverá directamente el archivo HTML generado.

Algunas consideraciones previas:

Necesitas tener permisos de escritura en el directorio donde pretendas guardar las páginas. (esto lo puedes conseguir fijando los permisos a 777).
Necesitas poder configurar la directiva ErrorDocument de tu servidor Apache. (algunos hostings no lo permiten).

[1] Configurar el Apache

Debemos añadir lo siguiente en nuestro .htaccess o en la configuración del servidor Apache:

ErrorDocument 404 genera_pagina.php

[2] Añadir el código necesario

Es necesario añadir un bloque de código al principio y al fin de cada script. A continuación una implementación de ejemplo:

//obtenemos el nombre de la página solicitada
$pagina = array_pop(explode('/',$_SERVER['REQUEST_URI']));
//iniciamos el output buffer
ob_start();
//.............................
//código que genera la página
echo 'hola';
//.............................
//obtenemos el output bufer
$contenido = ob_get_contents();
//guardamos la pagina estática
file_put_contents($pagina,$contenido);
//volcamos por pantalla y cerramos el output buffer
ob_end_flush();

Se puede guardar el anterior código en un script llamado "genera_pagina.php" sustituyendo la linea echo "hola" por el código de nuestra aplicación (p.e. con un include()) o podemos dividir el código en dos scripts y usar las directivas auto-append-file y auto-prepend-file para no tener que modificar nuestra aplicación (cortar por las lineas de puntos).

En el ejemplo se obtiene sólo el nombre de la página solicitada y se crea una archivo con el mismo nombre con el contenido de la respuesta. Pero no soporta directorios, está pensado para trabajar sobre un directorio en concreto o en una web sin directorios en las URL. Cambiando la primera linea del ejemplo podéis hacer que se comporte de otra forma, el ejemplo simplemente obtiene el último trozo de la URL usando como delimitador "/".

A diferencia de otras propuestas de cache aquí estamos modificando el Apache para que ejecute un script en caso de no encontrar una página. Es por esto que en vuestra aplicación debéis generar una página de error en el caso de que la página solicitada no exista. Lo correcto es que en esta página de error se envíe la header correspondiente tal y como lo haría el Apache por defecto:

header("HTTP/1.0 404 Not Found");

[3] Mantenimiento de la cache

Por ultimo nos falta programar un proceso en el cron para que elimine los archivos de la cache que han caducado. Por ejemplo para mantener una cache de una hora:

0 * * * * find /web -mtime +1h -print0 | xargs -0 rm -f

Se ha de sustituir "/web" por la ruta física donde tenemos nuestra aplicación web. Si no queremos programar un cron siempre podemos hacer lo anterior desde algún script PHP que se ejecute constantemente en nuestra web.

Lo que comento en este post no es nada nuevo, ya fue propuesto por Rasmus Lerdorf en el PHPCon del 2002 (aunque un poco caducada la presentación que enlazo merece la pena).

Entradas relacionadas:

Cache en memoria compartida con APC

Oriol — Wed, 02 May 2007 18:37:23 +0000

Como continuación del anterior post voy a explicar brevemente como montar una cache de objetos en memoria compartida usando APC. Esto nos permite disponer de una cache accesible para cualquier proceso Apache que se esté ejecutando en el servidor. Podemos guardar cualquier variable (resultados de queries, páginas html, cualquier tipo de objeto, etc.) y esta se conservará entre las distintas peticiones hasta que la borremos de cache o expire el TTL que queramos.

Una forma rápida de ver su uso es con un ejemplo:

$obj = new Objeto();
apc_store('key',serialize($obj),3600);
$result = unserialize(apc_fetch('key'));
var_dump($result);

Usando apc_store() guardamos $obj en cache durante una hora. Podemos recuperar o borrar $obj de la cache usando el identificador key. Es necesario realizar serialize/unserialize si guardamos datos como objetos o arrays, para variables simples no es necesario.

Para borrar el anterior objeto de cache:

apc_delete('key');

Para evitar el uso de define el cual es bastante lento disponemos de apc_define_constants() y apc_load_constants() para guardar y recuperar constantes de cache.

El APC ofrece una interfaz gráfica para ver el uso que hacemos de la cache, que opciones tenemos activas, archivos "compilados", variables almacenadas, etc. a la vez que nos permite borrar todo el contenido de la cache. Podemos obtener la misma información con la función apc_cache_info() y para borrar la cache tenemos apc_clear_cache() aunque la interfaz gráfica no deja de ser interesante.

Un snapshot de ejemplo:

Para instalarla en FreeBSD se trata de copiar el archivo /usr/local/share/doc/APC/apc.php en algún lugar dentro de nuestro document root del Apache.

Entradas relacionadas:

Instalación del APC (Alternative PHP Cache) sobre FreeBSD

Oriol — Thu, 26 Apr 2007 21:10:58 +0000

Como prometía en el post dedicado a la optimización de ADOdb voy a explicar como instalar el sistema de cache APC sobre un servidor FreeBSD 6.x. El APC (Alternative PHP Cache) es un sistema de cache de opcode para PHP, sirve para cachear el código intermedio del PHP y así no tener que interpretar todos los scripts en cada ejecución. Para almacenar este código "compilado" se usa la memoria compartida del sistema. A parte el APC nos ofrece funciones para poder almacenar y recuperar datos de cache.

El APC es una extensión PECL que no viene incluida por defecto con el PHP (esto cambiará con la futura versión 6). A continuación describo como instalar y configurar el APC sobre FreeBSD.

[1] Instalar el port

Suponiendo que tenemos instalado y funcionando un servidor web (Apache+PHP) sólo nos falta añadirle la extensión PECL con:

# portinstall pecl-APC

Si no trabajas con portupgrade:

# cd /usr/ports/www/pecl-APC/ # make install clean

Con esto compilamos e instalamos el APC. Si todo va bien acabará el proceso y podremos ver esta nueva linea en el archivo /usr/local/etc/php/extensions.ini:

extension=apc.so

Cuando lo compilas se dan a escoger tres opciones: MMAP, SEMAPHORES y PHP4_OPT. Es aconsejable seleccionar sólo MMAP y si trabajas con PHP4 la última también. La opción de SEMAPHORES dependiendo de tu sistema puede provocar cierta inestabilidad y no ofrece muchas mejoras en rendimiento.

La última versión del APC (pecl-APC-3.0.14) se compila siempre con soporte mmap aunque desactives la opción (o esto es lo que me pasa a mi en los servidores bajo FreeBSD).

Ahora sólo falta configurar correctamente las directivas apropiadas en el php.ini y un restart (o reload) del Apache.

[2] Configurando el APC

La configuración por defecto del APC es apropiada en muchas situaciones aunque bajo FreeBSD deberíamos configurar correctamente el tamaño de memoria compartida. Esto se consigue con las siguientes directivas:

apc.shm_segments=1 apc.shm_size=32

En FreeBSD el tamaño de memoria compartida por defecto es de 32MB. Puedes optar por aumentarlo o por dejarlo igual y usar varios segmentos configurando la directiva apc.shm_segments. Para aumentar el tamaño de la memoria compartida a 128MB en FreeBSD:

# sysctl kern.ipc.shmmax=134217728 # sysctl kern.ipc.shmall=32768

Si quieres conservar estos valores después de reiniciar el sistema debes añadirlos en /etc/sysctl.conf.

Se debe fijar SHMALL (kern.ipc.shmall) a SHMMAX/PAGE_SIZE. Este valor en el ejemplo descrito de 128MB de memoria compartida nos queda como: 134217728/4096 = 32768. Puedes ejecutar el comando pagesize para conocer el tamaño de una página de memoria (PAGE_SIZE) en tu sistema y ipcs -M para verificar la configuración de la memoria compartida.

También hacer notar en este punto que con la última versión del APC bajo FreeBSD no permite usar varios segmentos de memoria compartida y estás obligado a sólo usar un segmento, si necesitas más memoria debes aumentar el tamaño de memoria compartida del sistema.

El resto de directivas de configuración dependen mucho del tipo de aplicación PHP. Dependiendo del número de visitas, cantidad de archivos a cachear, frecuencia de cambio de los archivos, etc. Una configuración de ejemplo con pequeñas notas acerca del significado de las directivas usadas (en el archivo /usr/local/share/doc/APC/INSTALL tienes todas las directivas disponibles detalladas):

; Activa el APC apc.enabled=1 ; Número de segmentos de memoria compartida apc.shm_segments=1 ; Tamaño de la memoria compartida apc.shm_size=128 ; Un número aproximado de archivos fuente a cachear apc.num_files_hint=6000 ; Un número aproximado de variables a cachear apc.user_entries_hint=100 ; Segundos que dejamos en cache una entrada que ya no se usa apc.ttl=600 ; Idem al anterior pero para las variables de usuario apc.user_ttl=600 ; Segundos que dejamos una entrada cacheada en el recolector de basura apc.gc_ttl=0 ; Indica si se cachea por defecto. apc.cache_by_default=On ; Expresiones regulares para saber que archivos cacheamos ; Resulta útil si se usa en combinación con la directiva anterior apc.filters="" ; Indica si se activa el APC para el modo CLI del PHP apc.enable_cli=0 ; Indica el tamaño máximo de archivos a cachear apc.max_file_size=1M ; Indica si el APC ha de verificar si los archivos han sido modificados ; para actualizar la cache apc.stat=1

De todos los cacheadores de código que he usado APC es con diferencia el más estable aunque no es perfecto. En situaciones de mucho tráfico y si constantemente estás cambiando los archivos al final consigues un fantástico segfault del Apache. Una gran opción si dispones de una aplicación que no está en constante desarrollo es usar la directiva apc.stat a 0, con este parámetro consigues mucha más estabilidad.

Es un gran invento y es muy recomendable su uso, puedes llegar a ver loads de CPU reducidos al 50% y ganar un 20% de memoria. Pero como todo tiene bugs y al menos yo en el escenario donde lo uso (decenas de millones de páginas vistas por mes + clúster de decenas de servidores BSD) es un tanto inestable en ciertas situaciones... pero mucho más estable que algo como EAccelerator el cual en el anterior escenario no aguanta ni 5 minutos.

Si usas APC sobre FreeBSD en webs con mucho tráfico y no tienes ni un segfault nunca... no te cortes y comenta que directivas/opciones estás usando.

En un siguiente post explicaré como usar las funciones que proporciona el APC para almacenar datos de aplicación en cache.

Entradas relacionadas:

Creando imágenes on-the-fly con las GD en PHP

Oriol — Thu, 15 Mar 2007 03:12:39 +0000

GD es una librería de código abierto para la creación dinámica de imágenes. GD está escrita en C aunque puede ser usada desde varios lenguajes de programación entre ellos, como no, nuestro querido PHP.

A continuación describo como generar imágenes GIF "on the fly" usando PHP. Se puede usar este código para generar botones bajo demanda lo que resulta muy útil en distintas ocasiones, por ejemplo en webs que pretender ser traducidas a varios idiomas.

function genera_boton($text) {
header("Content-type: image/gif");
$font = '../fonts/ARIALNB.TTF';
$fontsize = 11;
$ycoord = 17;
$imgheight = 22;
$xpad = 40;
$details = imageftbbox($fontsize, 0, $font, $text);
$imgwidth = abs($details[2] - $details[0]) + $xpad;
$xcoord = ($imgwidth - $details[4]) / 2;
$im = @imagecreate($imgwidth, $imgheight)
or die('error generando la imagen');
$background_color = imagecolorallocate($im, 0, 0, 128);
$text_color = imagecolorallocate($im, 255, 255, 255);
imagettftext($im,$fontsize,0,$xcoord,$ycoord,$text_color,$font,$text);
imagegif($im);
imagedestroy($im);
}
genera_boton('HOLA MUNDO');

La imagen generada es muy simple y sólo debería servir de ejemplo, aunque con pocos retoques se puede conseguir algo mucho más bonito. La función genera un rectángulo azul con el texto $text centrado, se usa la fuente TrueType ARIALNB.TTF (disponible en cualquier Güindows).

Mediante la información devuelta por imageftbbox() se centra el texto automáticamente pero la altura de la imagen y la posición vertical del texto se fijan manualmente. Esto es así ya que si calculamos estos valores ($imgheight y $ycoord) pueden variar de forma no deseada dependiendo de la fuente usada y del texto que queremos mostrar, por ejemplo con el uso de acentos, mayúsculas o eñes obtendríamos imágenes con una altura mayor... y normalmente uno quiere que todos los botones tengan la misma altura :)

Si usas otra fuente o tamaño de fuente tendrás que ajustar los valores $ycoord e $imgheight. Probablemente también quieras ajustar $xpad que es lo que fija los márgenes izquierdo y derecho entre el texto y el borde de la imagen.

Paso a tratar un tema habitual en este blog, el rendimiento. Es muy interesante utilizar algún tipo de cache de los botones generados, a continuación propongo un par de ideas de cache (cliente y servidor):

[1] Usando el segundo parámetro de imagegif() guardar en disco el archivo GIF. Entonces podemos tirar de is_file() para comprobar si ya disponemos del GIF generado que con un simple file_get_contents() podremos recuperar. Aunque es mucho más óptimo configurar reglas de mod_rewrite del Apache para devolver el GIF directamente en caso de que exista el archivo.

[2] Enviar las headers de cache apropiadas al navegador del usuario. Por ejemplo tendremos cache de una semana añadiendo lo siguiente al inicio del código anterior:

header("Expires: ".gmdate("D, d M Y H:i:s", mktime(date("H"),date("i"),date("s"),date("m"),date("d")+7,date("Y")))."GMT");
header("Last-Modified: ".gmdate("D, d M Y H:i:s")."GMT");

Para finalizar añadir que puedes generar botones más bonitos usando imagecreatefrompng() para cargar imágenes que sirvan de plantilla. Otra opción es con funciones como imagepolygon() y imagerectangle() dedicar un buen rato a diseñar pero con PHP :)

Como no soy muy de diseño (ni con las GD), si alguien se ha currado botones más bonitos usando sólo funciones GD o sabe sitios donde encontrarlos... q no se corte!

Entradas relacionadas:

Optimización del rendimiento de ADOdb en PHP

Oriol — Wed, 06 Dec 2006 03:39:20 +0000

ADOdb es una librería de abstracción de base de datos para PHP muy potente. Dispone de una cantidad de usuarios y casos de éxito importante y ofrece muchas funcionalidades interesantes con soporte para una buena lista de engines de BD. Es un proyecto maduro, iniciado el año 2000, que si no conoces se merece una ojeada en su página oficial.

Como consecuencia de la cantidad de funcionalidades que ofrece es un layer tirando a lento (existen alternativas más rápidas y limpias). Esto es debido a que es un proyecto enorme con miles de lineas de código algunas de ellas, desgraciadamente, de no mucha calidad. Aunque a mi personalmente me gusta mucho y en todo proyecto software existen algunas partes un poco feas.

Dependiendo de la carga del site donde uses ADOdb o dependiendo de si necesitas todas sus funcionalidades es aconsejable estudiar bien otras alternativas mucho más lights. Como ADOdbLite (simulando ADOdb pero mucho más optimizada y con muchas menos funcionalidades), PDO (dispone de las características más importantes de ADOdb, es más rápida y se ha convertido en el estándar), PEAR MDB2 (sucesora de la clásica DB, potente y bastante rápida). Según John Lim, ADOdb no es que sea tan lenta, pero si la usas en un site con bastante carga y no realizas ninguna de las optimizaciones aquí descritas puedes estar perdiendo unos cuantos segundos en el total de una sesión de usuario (decenas o centenares de ms por página), y muchísimos más si entramos en el tema del uso de la cache de queries (que con esto ADOdb no es precisamente el culpable sino que proporciona un sistema de cache para el acceso a BD).

Es cierto que ADOdb arrasa en funcionalidades sobre las tres alternativas que he comentado pero como en muchas situaciones en el desarrollo en PHP vale la pena valorar las funcionalidades versus rendimiento. Estudiar bien el uso que le vamos a dar a la librería, la carga del site. frecuencia de las queries (dependiendo del tipo de web o de si disponemos de caches de contenido), etc.

Si a pesar de lo anterior te encanta ADOdb y lo quieres utilizar o si ya lo usas en algún proyecto y no puedes asumir un cambio, aquí van algunos consejos para mejorar el rendimiento del acceso a BD (optimizaciones para la librería y como usar la cache de queries).

[1] Usar la extensión de C de ADOdb. Si la instalas la librería PHP del ADOdb se encargará de usarla, aunque también puedes usar directamente las funciones adodb_* en tu código. Puedes descargarla aquí, dentro del archivo están las instrucciones para su instalación (archivo README.txt).

[2] Sobretodo, si tiras de la versión PHP de la librería usar un acelerador de código con opcode cache. Como APC o EAccelerator. Con sites con mucha carga, por mi experiencia personal, APC lo considero un sistema mucho más estable que el EA. El APC se instala como una extensión PECL del PHP.

[3] Usar la cache de ADOdb para tus queries. Esto se consigue con el uso de CacheExecute(). De las queries ejecutadas con este método se almacenan los recordsets devueltos a disco, esto es, con las siguientes queries idénticas el ADOdb devuelve el objeto serializado de disco hasta que no caduque.

Para poder usar CacheExecute() es necesario crear un directorio para la cache e iniciar el ADOdb como sigue:

$ADODB_CACHE_DIR = '/var/directorio_para_la_cache';
$db = NewADOConnection($dsn.'/'.$dbname);
$db->SetFetchMode(ADODB_FETCH_ASSOC);

Para lanzar una query almacenando cache durante un día:

try {
$sql = 'SELECT id FROM datos WHERE nombre="'.$n.'"';
$rs=$db->CacheExecute(86400,$sql);
// ...
} catch (ADODB_Exception $e) {
// ...
}

Contando claro que trabajamos con PHP5 y que hemos cargado el soporte para exceptions del ADOdb. Esto se consigue añadiendo:

require_once 'adodb/adodb-exceptions.inc.php';

[4] Es interesante valorar memcached como sustituto de la cache a disco por defecto. ADOdb incluye el código necesario para usarlo. Memcached es teóricamente más rápido que el acceso a los recordsets serializados a disco, aunque la principal ventaja que ofrece es la reutilización de la cache entre distintos servidores.

Una vez instalado memcached, para iniciarlo:

# memcached -d -m 512 -l 127.0.0.1 -p 11211 -u www

Para iniciar el daemon con 512 MB de memoria escuchando sólo en localhost y corriendo como usuario www. Cambiar 127.0.0.1 por la IP de vuestro servidor tanto en el comando como en el código PHP que sigue, y www por el usuario que ejecute el Apache. Es necesario instalar una extensión PECL para trabajar con memcached.

Para iniciar ADOdb y indicar que queremos usar memcached para nuestros CacheExecute:

$db = NewADOConnection($dsn.'/'.$dbname);
$db->SetFetchMode(ADODB_FETCH_ASSOC);
$db->memCache = true;
$db->memCacheHost = 'localhost';
$db->memCachePort = 11211;
$db->memCacheCompress = false;
$db->cacheSecs = 86400;

[5] Aunque bastante incómodo y en algunos casos peligroso (futuros ALTER TABLE) es más rápido acceder directamente a $recordset->fields mediante el ID numérico y fijar la variable $ADODB_FETCH_MODE = ADODB_FETCH_NUM.

[6] Finalmente podemos mirar de ejecutar los métodos _Execute() y _query() para lanzar nuestras queries. Estos son métodos mucho más crudos. _Execute() a diferencia de Execute() no emula binding, p.e. necesario para usar Prepare() si nuestra BD no lo soporta nativamente. Por el otro lado _query() si que es mucho más limitado, a parte de no emular binding tampoco devuelve recordset y no tiene debugging.

Con todo lo anterior podemos tener ADOdb bastante más optimizado aunque si tenemos un nuevo proyecto por delante quizás lo más aconsejable es usar PDO dado que todo apunta a que se convertirá en el estándar a seguir para el acceso a base de datos en PHP.

Acerca del tema de la cache de queries, sin ánimo de alargar más el post, sólo decir que es mucho más óptimo usar memcached para cachear objetos que no cachear las queries necesarias para generar estos objetos... si disponemos de unos buenos sistemas de caches de contenido (p.e. squid) y un sistema de cache de objetos genérico (memcached) cachear las queries deja de ser tan importante aunque te ofrece otro nivel de cache para jugar.

En un siguiente post dedicado a los sistemas de cache en PHP explicaré con más detalles como trabajar con APC y Memcached sobre servidores FreeBSD.

Entradas relacionadas: