1blogcacher vs WP-Cache
Publicado el Jueves 13 de Septiembre del 2007 @ 12:20 por Armonth.
- 18
- 4
Comentar
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.
18 Comentarios (feed)
-
InKiLiNo nos comenta:
Pues tendremos que probarlo a ver que tal, sobretodo la simultaneidad con otros plugins, que es lo que a mi me ha dado algún problema con WP-Caché.
-
Javier García nos comenta:
Hola Héctor, gracias por la mención,
Estoy tomando buena nota de todo lo que estáis comentando en diferentes webs. Te copio lo que respondí en otro sitio, porque se aplica también a lo que escribes:
(http://www.buayacorp.com/archivos/wp-cache-vs-1blogcacher/#comment-23304)
“Cuando lo desarrollé mi idea era crear un sistema de cacheo sencillo, y que se instalara como un plugin al uso (subir e instalar), pero ahora me doy cuenta que con ello se ve limitado por lo que comentas.
Estoy desarrollando una nueva versión que, manteniendo el sistema, hace uso del advanced-cache de WordPress así que mejorará en tiempo de respuesta y sobre todo en consumo de memoria. Y la instalación seguirá siendo simple, la diferencia con la versión anterior será sólo subir un archivo adicional. Había algunas dificultades técnicas para usar este sistema con el advanced-cache y mantenerlo simple, pero ya las he solventado y pronto publicaré la nueva versión.
Además, a petición de algunas personas, incorporaré bloques dinámicos.”.
Aparte de lo que ahí comentaba, lo que dices de cachear también la versión comprimida para ahorrar consumo de CPU es una gran idea, y también la incluiré. Espero tener lista la nueva versión en unos días.
Saludos
-
Javier García nos comenta:
Por cierto, no es por difamar a la “competencia”, pero al enviar el anterior comentario me ha aparecido ésto:
Warning: unlink(/home/.cerridwen/arm0nth2k6/sigt.net/wp-content/cache/wp-cache-3cd6e255d62333797a5a06d8d7618f44.html) [function.unlink]: No such file or directory in /home/.cerridwen/arm0nth2k6/sigt.net/wp-content/plugins/wp-cache/wp-cache-phase2.php on line 297
:D
-
Armonth nos comenta:
Ya javier, eso pasa cuando el “manazas” del webmaster borra el cache a lo bruto con un “rm” y por el camino se carga el mutex, nada raro :-P
-
alex nos comenta:
“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”
Como parte de unas pruebas, implementé esa parte de generar dos versiones para cada archivo, pero este método no sirve para páginas que usan mfunc/mclude.
En fin, particularmente yo no veo características de 1BlogCacher que no puedan ser sencillamente implementadas/habilitadas en WP-Cache.
-
Armonth nos comenta:
Alex… er… no me queda claro, a ver supongamos el siguiente esquema:
WP-Cache (PHP) busca la página estática -> ve que está -> ve que es dinámica -> ejecuta la parte de código correspondiente a dinámica -> Apache mediante deflate la comprime -> es enviada.
Si la página está comprimida con gzip y WP-Cache mediante negociación da soporte para enviar comprimida o no… al enviarla comprimida ¿no debería ejecutar primero el PHP?. En ése supuesto el esquema debería ser casi igual (el penúltimo paso omitido).
No sé, quizá es que PHP no puede leer el contenido en gzip o no vale la pena xD, ni lo había pensando pero en tal caso otro motivo más para enviar la página comprimida vía mod_deflate/mod_gzip sin guardarla en cache…
-
alex nos comenta:
Héctor, el problema es que justamente PHP no puede interpretar el código que está en ficheros comprimidos, así que la opción más saludable, como dices, es hacerlo con mod_deflate/mod_gzip.
-
Armonth nos comenta:
Ok alex, bueno es confirmarlo…
-
Victor nos comenta:
Lo acabo de instalar (antes tenía wp-cache) y en un principio 1BlogCacher 2 creo que es mejor que wp-cache.
Ahora por ejemplo, con 45 consultas:
Cargado en 0.40 segundos (2008-01-13, 13:28:53). Memoria usada: 448.9 KB de 449 KB.
El uso de memoria igual lo veo un poco excesivo, utilizo:
Memoria usada: “.round(memory_get_usage() / 1024,1).” KB de “.round(memory_get_usage(1) / 1024,1).”KB ”
Seguiré haciendo pruebas.
¿Cómo veis los resultados?
Un saludo.
-
Armonth nos comenta:
Victor pues depende de los valores, no es “mucho” ya que sin cachear un WordPress puede consumir entre 5 y 8 megas de RAM (¡¡!!) y en base a eso el consumo de RAM una vez cacheada en SigT ha sido el siguiente:
- Blogcacher 1: 5500KB (casi sin reducción).
- Blogcacher 2: 380KB (al ejecutarse al principio y matar el script igual que el WP-Cache pues se reduce bastante).
- WP-Cache: 210KB
De todas formas el consumo que tienes no es alto.
-
Victor nos comenta:
Armonth entonces wp-cache es más efectivo que Blogcacher 2 (?¿)
-
Armonth nos comenta:
Al menos en mi caso particular así ha sido.
-
MinimalNet nos comenta:
Armonth yo creo que tengo un problema con el wp-cache. Intento explicar lo que me pasa.
Deslogueado en mi blog entro a una página que acabo de ver que está cacheada (desde la página de configuración del wp-cache), y sin embargo la vuelve a cachear.
Esto lo sé porque debajo, en el footer, veo la memoria consumida y son 8000 y pico kb.
Luego ya si vuelvo a esa página de nuevo, o doy a refrescar, ya me carga el caché, por lo que me pregunto si wp-caché me está cacheando las páginas de manera individual para cada visitante.
¿Esto es así?, porque si fuera así ¿qué ventaja tiene entonces usar el wp-cache?.
-
Armonth nos comenta:
Creo que tenía algo que ver con cómo se programa la cache para usuarios. No es lo normal pero de todas formas eso, cuando pasa, sólo pasa con los usuarios registrados en el blog que son una ínfima minoría comparada con los visitantes…
-
MinimalNet nos comenta:
Armonth pero todo esto es estando deslogueado, ¿cómo sabe el wp-cache que soy un usuario registrado?, ¿por la IP?
-
MinimalNet nos comenta:
O sea, yo entro a la página de configuración del wp-cache, veo la lista de páginas cacheadas, me fijo en una que no haya visitado yo mismo, la anoto, me deslogueo y entro a esa página ya cacheada por otro usuario anteriormente, y en vez de enviar el caché me la carga de nuevo.
-
Armonth nos comenta:
Minimal, por las cookies se puede saber aunque la IP cambie. También puede ser que tengas algo mal, lo cual no sé ya que este comportamiento no lo he visto muy a menudo.
-
Juan nos comenta:
Hola a todos,
Tengo un par de preguntas para los expertos:
1) Uso en el footer de wordpress la línea: Memoria usada: “.round(memory_get_usage() / 1024,1).” KB de “.round(memory_get_usage(1) / 1024,1).”KB ” -> pero esta me devuelve: “9108.1 KB de 9108.1 KB. ” ¿Es normal que me devuelva ambos valores idénticos?
2) ¿Es normal ese consumo?
Nota:. Estoy usando la versión 2.3.2 de Wordpress. En principio no puedo actualizarla y debo seguir con esa versión por causas de fuerza mayor.
Nota2: Versión de PHP del server dedicado: 5.1.6A ver si alguien me puede ayudar…
¡Gracias!