WP-Cache vs 1BlogCacher

Tanto WP-Cache como 1BlogCacher son plugins para WordPress que almacenan copias estáticas de las URLs accedidas, esto con el objetivo de incrementar la velocidad de respuesta y reducir la carga del servidor.

Cuando vi el anuncio de 1BlogCacher y sin haber probado el plugin, tenía algunas sospechas de que era más limitado que WP-Cache. Luego de ver los números que publicó Andrés en relación al comportamiento de éstos plugins, me llamó la atención el número de peticiones fallidas que tenía WP-Cache, por lo que decidí hacer una prueba y explicar el posible motivo de estas fallas.

El entorno sobre el que se realizó esta pequeña prueba es:

Sistema Operativo
Debian Sid (Kernel 2.6.22-1-686) sobre VMWare.
Servidor Web
Apache/2.2.6 + PHP 5.2.3-1+b2.
Servidor de Base de Datos
MySQL 5.0.27 sobre Windows XP*.
WordPress
Versión en desarrollo.

Número de páginas servidas

Para la prueba, al igual que Andrés, utilizo Apache Benchmark con los siguientes parámetros : ab -c5 -t10 http://localhost/wp/, que equivale a hacer la prueba durante 30 segundos con nivel de concurrencia 5.

-c concurrency Number of multiple requests to perform at a time. Default is one request at a time.

-t timelimit Maximum number of seconds to spend for benchmarking. This implies a -n 50000 internally. Use this to benchmark the server within a fixed total amount of time. Per default there is no timelimit.

Prueba sin ningún plugin activado:

code:
hell:~# ab -c5 -t30 http://192.168.1.202/~alex/wp1/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.1.202 (be patient)
Finished 236 requests


Server Software:        Apache/2.2.6
Server Hostname:        192.168.1.202
Server Port:            80

Document Path:          /~alex/wp1/
Document Length:        4904 bytes

Concurrency Level:      5
Time taken for tests:   30.338809 seconds
Complete requests:      236
Failed requests:        1
   (Connect: 0, Length: 1, Exceptions: 0)
Write errors:           0
Total transferred:      1225765 bytes
HTML transferred:       1162249 bytes
Requests per second:    7.78 [#/sec] (mean)
Time per request:       642.771 [ms] (mean)
Time per request:       128.554 [ms] (mean, across all concurrent requests)
Transfer rate:          39.45 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.5      0       8
Processing:   131  632 1551.8    474   22284
Waiting:      131  631 1551.7    474   22283
Total:        131  632 1551.7    474   22284

Percentage of the requests served within a certain time (ms)
  50%    474
  66%    540
  75%    609
  80%    635
  90%    742
  95%    866
  98%   1081
  99%   5015
 10022284 (longest request)

Prueba con 1BlogCacher activado:

code:
hell:~# ab -c5 -t30 http://192.168.1.202/~alex/wp1/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.1.202 (be patient)
Finished 359 requests


Server Software:        Apache/2.2.6
Server Hostname:        192.168.1.202
Server Port:            80

Document Path:          /~alex/wp1/
Document Length:        5084 bytes

Concurrency Level:      5
Time taken for tests:   30.83504 seconds
Complete requests:      359
Failed requests:        0
Write errors:           0
Total transferred:      1915920 bytes
HTML transferred:       1830240 bytes
Requests per second:    11.93 [#/sec] (mean)
Time per request:       418.990 [ms] (mean)
Time per request:       83.798 [ms] (mean, across all concurrent requests)
Transfer rate:          62.19 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:    80  413 695.4    302    7783
Waiting:       80  413 695.3    302    7783
Total:         80  413 695.4    302    7783

Percentage of the requests served within a certain time (ms)
  50%    301
  66%    374
  75%    480
  80%    553
  90%    684
  95%    804
  98%    850
  99%   2017
 100%   7783 (longest request)

Prueba con WP-Cache activado:

code:
hell:~# ab -c5 -t30 http://192.168.1.202/~alex/wp2/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.1.202 (be patient)
Completed 5000 requests
Completed 10000 requests
Finished 10057 requests


Server Software:        Apache/2.2.6
Server Hostname:        192.168.1.202
Server Port:            80

Document Path:          /~alex/wp2/
Document Length:        4992 bytes

Concurrency Level:      5
Time taken for tests:   30.2791 seconds
Complete requests:      10057
Failed requests:        0
Write errors:           0
Total transferred:      53382556 bytes
HTML transferred:       50204544 bytes
Requests per second:    335.20 [#/sec] (mean)
Time per request:       14.916 [ms] (mean)
Time per request:       2.983 [ms] (mean, across all concurrent requests)
Transfer rate:          1737.54 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    4   2.9      5      16
Processing:     2    8  52.8      8    3904
Waiting:        0    5  52.8      5    3902
Total:          2   13  52.8     14    3907

Percentage of the requests served within a certain time (ms)
  50%     14
  66%     14
  75%     14
  80%     14
  90%     15
  95%     15
  98%     16
  99%     17
 100%   3907 (longest request)

En mi humilde opinión, el número de peticiones fallidas en las pruebas que hizo Andrés, se debe a que el tiempo de la prueba era muy corto para 100 peticiones.

Consumo de memoria

Otro punto importante a tomar en cuenta es el consumo de memoria por petición:

La enorme diferencia en el consumo de memoria entre ambos plugins, se debe principalmente a que WP-Cache utiliza la funcionalidad que WordPress provee para el cache estático y termina la ejecución del script antes de que se incluya gran parte de los archivos que forman parte del mismo (es por este motivo que muchos plugins no funcionan con WP-Cache).

Conclusiones

Para blogs con bastante tráfico WP-Cache sigue siendo la alternativa más adecuada en relación a 1BlogCacher, porque además de servir más páginas por segundo, también reduce considerablemente el consumo de memoria.

Al parecer las pruebas empíricas que hice confirmaron mis sospechas iniciales con respecto a las limitaciones de 1BlogCacher. Si cometí algún error, pueden indicármelo en los comentarios. 😉

*: no tenía ganas de bajar algo de 30 MB sólo para hacer la prueba en Debian. 😀

24 Replies to “WP-Cache vs 1BlogCacher”

  1. Hola Alex,

    Gracias por probar el plugin. 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.

    Saludos

  2. @ Alex

    Ayer recibí este mensaje de Quiñonero: "...Cada día me maravillo, comprobando que NO entra ningún spam en UTI. Tu sabrás que has hecho. Gratitudes".

    Desde junio no se cuela ni uno, ni tan siquiera en moderación, gracias al fichero modificado WP-trackback.php que te envíe días atrás. Debieras anotar al respecto del fichero, si le encuentras fallos de seguridad... pues creo que interesaría a muchos de tus lectores.

  3. Javier, esta entrada no tiene intención de despreciar el trabajo que hiciste, sólo que después de ver el código y los números que publicó Andrés, no me parecían del todo correctos. 🙂

    Por cierto, en mi opinión, tu plugin no debería almacenar en cache páginas no encontradas.

    Maty, sobre el código que me pasaste, aunque todavía no tuve la oportunidad de probarlo, te puedo asegurar que no tiene ningún problema de seguridad.

  4. Alex, sin ningún problema, tus comentarios han hecho que el plugin vaya a mejorar mucho en rendimiento.

    "Por cierto, en mi opinión, tu plugin no debería almacenar en cache páginas no encontradas.". Ahí no estoy de acuerdo, una página 404 es una página igualmente y consume CPU como cualquier otra. Imagina que Google te posiciona bien una página a la que por alguna razón le cambias la url y empieza a devolver un 404... Si te manda el suficiente tráfico a esa url y no la cacheas estarás arriesgándote a sobrecargar el servidor.

  5. Javier, en parte tienes razón, pero lo decía por un problema (devuelve una página en blanco) que sucede en WordPress 2.3; en esa versión, cuando una URL genera un 404 existe nueva funcionalidad que intenta redireccionar a una entrada que coincida -- en parte -- con la URL que se estaba buscando (ver el segundo punto de [1]), imagino que pasa lo mismo con plugins que realizan esta tarea.

    Por otro lado, durante las pocas horas que probé tu plugin, experimenté los siguientes problemas con la versión en desarrollo de WordPress:
    - Devuelve una página en blanco cuando la estructura de permalinks termina en /. (Ejm /archivos/%postname%/)
    - Cuando cambia el slug (o url) de una entrada no se elimina del cache la página anterior, esto es contraproducente porque producirá contenido duplicado (antes de solucionar esto, tienes que tomar en cuenta que WordPress hace una redirección 301 a la página que contiene la nueva URL).

    Finalmente, el ejemplo que pones es algo extremo, puesto que si esa URL está bien posicionada lo más lógico es que hagas una redirección a la nueva página 😀

    [1] http://www.buayacorp.com/archivos/novedades-de-wordpress-23/

  6. Alex, sí, en los dos casos (404 y permalinks acabados en "/") se trata del mismo problema, hay una redirección por lo que no se devuelve contenido (sólo headers). Sólo es comprobar eso, de hecho creía que el plugin lo hacía, pero veo que no. Sin problema, lo añado.

    "si esa URL está bien posicionada lo más lógico es que hagas una redirección". Yo sí, mucha gente no sabría ni cómo hacer eso. Sigo sin ver ningún motivo para no cachear los 404, son páginas como otras cualquiera. Si me das una sóla razón para no cachear...

  7. Javier, yo sigo creyendo que no es necesario cachear páginas no encontradas pero no soy el más indicado para decirte que implementar y que no 🙂 , puesto que por el momento no pienso utilizar tu plugin, si en un futuro lo hago y necesito alguna característica en particular, seguramente seré yo quien tenga que implementarla para no abusar de tu trabajo. 😉

  8. La única razón que se te puede ocurrir para no cachear los 404 es que alguien vea que estás usando el plugin de cacheo y haga un script para hacer miles o millones de peticiones y que te quedes sin disco duro. Pero eso mismo lo pueden hacer sin los 404, simplemente añadiendo diferentes querystring a páginas que existen: http://www.buayacorp.com/?fake=1, http://www.buayacorp.com/?fake=2...

    Así que si cachear los 404 no tiene nada perjudicial (yo al menos no veo nada), y sí tiene de beneficioso (porque es posible ahorrar CPU), creo que la decisión es obvia...

    Por cierto, me he replanteado el tema de los headers, para redirecciones y demás, y voy a añadir un sistema que los gestiona mejor. Así se cachearán incluso las redirecciones, p ej en WordPress 2.3 para las redirecciones que comentabas no se tendrá que cargar todo WordPress para hacerlas, sino que se ejecutarán en el advanced-cache.

  9. Hola,
    Se que la pregunta es muy tonta, pero no consigo hacer funcionar el parche para que el wp-cache muestre la memoria que esta consumiendo el wordpress en el servidor....

    Modifico el wp-cache-phase1.php y aparentemente no hay ningun problema, sin embargo no consigo averiguar DONDE debo mirar para ver el valor que me devuelve el script 🙁

    ¿Alguien me puede echar una mano?

    Un saludo,

  10. Ese número aparece como comentario HTML, así que tienes que ver el código fuente de tu blog para poder apreciarlo (no creo que ese valor sea de interés para tus lectores 🙂 ).

  11. 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.

Comments are closed.