Eso, al menos, es lo que le parece a Jeff Atwood, quien se ha dedicado a analizar en Coding Horror el consumo de CPU de dos instalaciones de WordPress (WP). Según plantea, la voracidad del cms más popular de la blogosfera es muy alta ya en su versión básica (20 peticiones a la base de datos de serie), pero puede ser prácticamente infinita a poco que comiencen a utilizarse plugins o a subir el tráfico.
Atwood ha comprobado el mismo consumo instalando algunos de los plugins que se encargan de cachear las páginas dinámicas creadas por WP y convertirlas en páginas estáticas, y certifica que el consumo se reduce de forma considerable, por lo que no entiende cómo este sistema de caché no ha sido incorporado ya al código base.
Sin embargo, hay que tener en cuenta que las pruebas están hechas con un servidor dedicado Windows Web Server 2008, algo que muchos usuarios han criticado en los comentarios, pues aseguran que es precisamente ese tipo de servidor el que puede crear problemas. Por otro lado, Atwood señala que tiene habilitado en el servidor la opción FastCGI, algo que desde hace mucho tiempo, en mi etapa de Dreamhost, me indicaron que había que deshabilitar si no quería fundir la máquina en un plis plas.
En cualquier caso, la polémica sigue en pie. Y la conclusión de Atwood no me parece mala: ¿para cuándo un buen sistema de caché oficial en las instalaciones básicas de WP?
8 comentarios
De seguro esa será la gran novedad en WordPress 2.6. Un buen sistema de cache, y WordPress sería insuperable
En el host que estoy tiene FastCGI y no parece haber tanto problema; al menos se preocupan mas del gasto de ancho de banda.
La idea de incluir una sistema de cacheo en WordPress no es nueva, tampoco las quejas de muchos usuarios acerca del consumo de CPU y Gasto de Memoria… si no me falla la memoria ricardo galli apuntaba esto mismo con la sencilla frase “WP is a Pig” y esta misma idea fue el principal motivo para crear WP Cache.
El tema de integrar un sistema de cache a WordPress es una discusion de hace ya tiempo en wp-hackers de vez en cuando se vuelve a tomar la discusión pero todas acaban con lo mismo… “debemos dejar espacios para que se pueda desarrollar cada quien o bien terceros sus propios sistemas/plugins de cacheo”, por que hacen o piensan esto? es simple: La heterogeneidad en los Servidores Web.
Esto dificulta un poco la creación del cacheo automático ya que no queremos pedirle al usuario que haga X labor antes de instalar, ya que recuerden la instalación y manejo debe ser sencillo no estar lleno de dale permisos de escritura a esto… etc…, si no pues ya se caería en el mismo bando de competencia que de MovableType que prácticamente esto hace.
Mis apuestas sobre el cacheo (que posiblemente llegue en la 2.6) van hacia un sistema de cacheo-minimal estilo Drupal, el cual se basa en pre-procesar y guardar la mayoría de los datos adentro de una tabla especializada y así solo tomar la información directamente de la BD esto reduciría hasta un 80% las querys y gasto de CPU (aunque claro la memoria se mantendría y posiblemente aumentaría).
Tal vez vemos para la versión 3.0 se vea una integración con WP Cache pero por ahora el equipo de WP no se muestra muy animado como para tomar la idea y aunque hay/hubo un proyecto de cacheo en GSoC este mismo parece que no tuvo gran exito.
Saludos
@Alejandro Martinez yo creo que para que WP sea insuperable, tendrian que modificar la administracion, por que con la 2.5 ahora es mas bonita, pero menos funcional. A ver si lo arreglan un poco. Tambien espero que sea algo mas rapido, por que he notado bastante un rendimiento bajisimo con la actualizacion 2.3 a 2.5.
Y claro, una vez están, que implementen correctamente los videos (no me funciona la implementacion oficial), las imagenes (la nueva redimension no me funciona nada bien) y la forma de gestionar los widgets (es menos intuitiva y no me guarda bien el contenido ni la configuracion de los Widgets)
Con eso, creo que WP si que seria insuperable 🙂
[…] comenta en Mangas Verdes, esta prueba ha sido bastante criticada porque está realizada con Windows Web Server 2008, cuando […]
Creo que además del cacheo estaría bien soporte completo para php-eaccelerator, aunque no se si a nivel de programación hay que hacer algo, y luego soporte de memcached, que son muchos los servidores los que ya van haciendo uso de el.
Y así estamos todos, pagando una pasta gansa en servidores porque WP hace peticiones sin parar!
No es normal que mi blog con 3.000 visitas haga más de 50 peticiones al servidor, así no hay manera de trabajar…
P.D: que añadan también a la lista de tareas pendientes la de reducir el consumo de RAM de Firefox…
Solamente una corrección, FastCGI es casi tan rápido (o dicho de otra manera: consume tan poco) como mod-php que es la opción más recomendable. Lo que en su momento te debieron comentar es “CGI”.
CGI = Cada vez que carga la web, ejecuto PHP, proceso y cierro PHP para volver a abrirlo a la próxima petición.
FastCGI = PHP se queda en memoria (sin consumir CPU y ocupando sólo un poco de RAM) esperando las peticiones…
Y aunque diga PHP, esto mismo sirve para Perl, Python, etcétera.