1blogcacher vs WP-Cache

Autor: Armonth | El jueves 13 de septiembre del 2007 @ 12:20.

1blogcacher es un plugin basado en WP-Cache pensando para hacer lo mismo: cache de páginas en WordPress. La diferencia es que pretende añadir nuevas características.

Copio y pego:

  • Compatible con Wordpress 1.5 y superiores (probado en 1.5, 2.0, 2.1 y 2.2).
  • Instalación/configuración rápida y sencilla.
  • Portable: edita el archivo para tu conveniencia y úsalo en cualquier sitio.
  • Los archivos cacheados se guardan en archivos HTML, y se organizan en directorios que emulan las urls, así que es fácil mostrar el contenido de los archivos y organizarlos (por ejemplo borrar la caché de una entrada específica, de todas las categorías. de todas las búsquedas, de todas las entradas de una fecha determinada, etc.)
  • Si «safe_mode» está habilitado, el plugin todavía funcionará, creando todos los archivos en el directorio de caché.
  • Opción para borrar todos los archivos cacheados (o sólo los espirados) desde el panel de WordPress.
  • Tiempo de expiración para los archivos cacheados.
  • Cadenas de texto aceptadas y rechazadas para controlar exactamente las urls a cachear.
  • User Agents rechazados para evitar sobre-cacheado proveniente de buscadores.
  • Los archivos cacheados (incluyendo la caché de la página inicial) serán actualizados cuando las entradas y los comentarios serán publicados/editados/borrados.
  • Opción de incluir un encabezado «Expires» para habilitar la caché del navegador (una velocidad de respuesta aún más rápida y menos peticiones de página).
  • Sólo las peticiones GET serán cacheadas.
  • Los usuarios registrados no ven páginas cacheadas.
  • La super-recarga del navegador (Ctrl+F5) evita las urls cacheadas.
  • Compatible con la compresión Gzip.

Novedades ¿necesarias?

Si bien reconozco que no he mirado al 100% el código me llama la atención esos tres puntos que he puesto en negrita. Veamos por qué:

El uso de cabeceras "Expires" es lo que recomendaban hace dos días en AskApache, una entrada en inglés que permite habilitar las cabeceras de Cache-Control y Content-Length. Buena parte de esa implementación está en el WP-Cache original. Pero con el código comentado, el motivo:

\/ No used to avoid problems with some PHP installations \/

Y es que si no recuerdo mal, PHP funcionando como CGI da problemas en esos casos o lo que es lo mismo: es posible (que no seguro) que 1blogcacher no sea tan compatible como WP-Cache pese a que éste ya de por sí ha tenido problemas con versiones modernas de PHP (al igual que WordPress).

También se puede extrapolar que aplicando ése parche si tu instalación de PHP no da problemas puede mejorar incluso más el rendimiento.

Otro asunto es el del uso de gzip: añadir compresión gzip a los documentos está muy bien (yo llevo tiempo pidiendo a Ricardo a ver cuándo puede incorporarlo) pero lo ideal sería cachear dos copias de cada documento: comprimida y sin comprimir, la compresión "al vuelo" no me convence en algunos casos... y sin embargo mi hosting (Dreamhost) la usa: y va de lujo, pero me pregunto si usar dos compresiones a la vez puede ocasionar problemas...

Y la segunda compresión (el DEFLATE que hace el server) en muchos casos como en el de Dreamhost no siempre se puede desactivar vía .htaccess (depende del server).

Rendimiento

Otro asunto preocupante es el consumo de memoria, el (aparentemente raro) diseño de WP-Cache no es baladí o un capricho: está hecho para que si existe una copia cacheada evite la carga de WordPress y por tanto consumir lo mínimo posible.

1blogcacher para enviar una página estática carga hasta el 75% del código de WordPress (y meter el 75% de 6MB en memoria para enviar un HTML... como que no). WP-Cache en ése sentido si existe una página cacheada para el código de WordPress y el consumo nunca lo he visto superior a 200KB de memoria.

Eso puede suponer una desventaja para WP-Cache: significa que no puedes acceder a funciones o código del propio WordPress desde una página cacheada pero, aparte de algo necesario, es la única manera de reducir drásticamente el consumo de memoria. Además una vez tienes la página cacheada ¿necesitas acceder a algo de WordPress? Muy pocas veces y en esos casos puedes reescribir la función a un fichero externo para ejecutarlo dinámicamente.

  • Peticiones a portada (lo de siempre: ab -t 10 -c 10):
  • Sin cache: 6.81 peticiones/seg.
  • WP-Cache: 73.29 peticiones/seg.
  • 1blogcacher: 22.10 peticiones/seg.

Conclusión

A 1blogcacher le falta un buen pulido, aunque me pregunto (sobretodo en el tema de la memoria) si para equipararse a WP-Cache no lo convertirán en otro WP-Cache, perdiendo sus ventajas por el camino.

Si vais a usarlo dos recomendaciones:

  • Probad el rendimiento de ambos sistemas.
  • No lo hagáis en un blog "en producción": uno tiene ya una larga vida y ha demostrado que sobrevive a ataques crueles como el efecto Slashdot, el otro por ser nuevo todavía no ha tenido tiempo para ponerse a prueba.

Comentarios