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:
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
Failed requests: 1
(Connect: 0, Length: 1, Exceptions: 0)
Write errors: 0
Total transferred: 1225765 bytes
HTML transferred: 1162249 bytes
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
100% 22284 (longest request)
Prueba con 1BlogCacher activado:
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
Failed requests: 0
Write errors: 0
Total transferred: 1915920 bytes
HTML transferred: 1830240 bytes
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:
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
Failed requests: 0
Write errors: 0
Total transferred: 53382556 bytes
HTML transferred: 50204544 bytes
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:
- 1BlogCacher: de los
5153.2 KBque consume WordPress en el servidor de prueba, cada petición de una página servida del cache consume4654.4 KB(parche para ver el consumo de memoria en 1BlogCacher). - WP-Cache: de los
5153.2 KBque consume WordPress en el servidor de prueba, cada petición de una página servida del cache consume tan solo172.7 KB(parche para ver el consumo de memoria en WP-Cache).
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 on “WP-Cache vs 1BlogCacher”
Muchas gracias! no tenia idea del otro plugin y me ahorraste el benchmarking ^_^
[...] Alex de Buyacorp hace nuevas pruebas y obtiene resultados bastante interesantes. Compártelo « Traduciendo WordPress 2.3 Los [...]
[...] WP-Cache vs 1BlogCacher - (buayacorp) 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. [...]
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
@ 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.
A lo que iba, también comentan sobre el susodicho plugin en:
SigT 1blogcacher vs WP-Cache
anieto2K 1BlogCacher, plugin para cachear WordPress
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.
[...] WP-Cache vs 1BlogCacher en Buayacorp - Diseño y Programación [...]
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.
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/
[...] Ya tenemos los resultados de las pruebas del plugin 1BlogCacher para WordPress, efectuadas por Andrés Nieto, Sigt y Buayacorp. [...]
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...
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. 😉
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.
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,
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 🙂 ).
mmm me deja un poco mas convencido de usar el wpcache! gracias
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.
Esta prueba se hizo en la primera versión que liberó Javier, me parece que él hizo algunos cambios después.
[...] Comparativa 1BlogCacher vs WP-Cache (Buyacorp) [...]
[...] SuperCache o ViperCache, esto lo dejo a tu gusto y experiencia, pero si quieres puedes revisar estas [...]
Y qué opinas del Super cache?
[...] de Cacheo de las páginas de tu blog, como SuperCaché, o 1BlogCacher. En este post de aNieto2k o en éste de Buayacorp podrás decidirte por cuál [...]
[...] Ya sólo falta que Alex (Buayacorp) actualice su comparativa. [...]