Aún tengo pendiente probar a fondo Nginx y Varnish, pero estos dias he estado aprovechando el cambio de servidor para montar todo el sistema sobre un Squid como proxy transparente ante Apache. Los cambios que he tenido que hacer al código han sido nimios en la mayoria de los proyectos alojados, aunque para uno de ellos, con múltiples controles por IP, Anti-spam, etc, he tenido que hacer alguna floritura.

El software que utiliza Propiedad Provada como CMS es el archivonocido WordPress, que como es igualmente archiconido, es una auténtica patata a la hora del rendimiento. Muchas, muchísimas consultas MySQL, muchas de ellas redundantes, índices no del todo bien definidos en la base de datos, código poco optimizado… agravado sobre todo por la instalación de addons y plugins de todos los tamaños y colores en muchas ocasiones bastante peores para el rendimiento que el propio CMS en si.

Pero no todo es malo, su sencillez es tremenda y obviamente es todo un standard a la hora del «blogging», asi que de lo perdido saca lo que puedas: si consigo que la nueva máquina sirva páginas de este blog como es debido, las que sirva de mis proyectos de trabajo, optimizadas para rendimiento, deberían salir como auténticas flechas.

Asi que he metido el blog en la misma máquinas de producción que las páginas de la empresa, y me he puesto manos a la obra. Tras un par de horas de investigar Headers, estudiar el código de WordPress, etc… anoche logré mis objetivos con sólo dos cambios:

1.- En mi php.ini

session.cache_limiter = public

2.- En el código de WordPress 2.6.3 (puede diferir según versiones), fichero wp-includes/classes.php linea 197, he comentado esta linea:

nocache_headers();

Dicha linea envia Headers de no-cache a usuarios no conectados, con lo cual obtengo un no-cache para mí cuando estoy logueado (viendo todo fresquito y a tiempo real), y un cacheado perfecto para usuarios no logueados (cacheado que en Apache tengo definido a 5 minutos, asi que tampoco es traumático).

Un reinicio rápido de Apache y Squid, y a probar con Apache Benchmark, 1000 peticiones de páginas con 50 usuarios concurrentes. Para ello tengo un pequeño script «made in feito por min» en bash, que contiene lo siguiente:

Archivo stress.sh:

/usr/local/apache/bin/ab -n1000 -c50 -q -k -H ‘Accept-Encoding: gzip,deflate’ $1 | grep ‘per second’ | awk ‘{print «Peticiones por segundo: » $4 }’

al que llamo en la forma:

./strees.sh http://urlacomprobar

Resultados antes de Squid:

./strees.sh http://www.propiedadprivada.com/
Peticiones por segundo: 8.12

Resultados con Squid:

./strees.sh http://www.propiedadprivada.com/
Peticiones por segundo: 5432.89

Lo que representa una mejora del…

Peticiones por segundo antes: 8.12
Peticiones por segundo con Squid: 5432.89
Formulita para calcular la mejora: ((5432,89-8,12)/8,12)*100

Resultado: Una mejoría total del…

¡¡¡ 66807,51 % !!! < - OMFG

Ale, esta semana me he ganado el sueldo; Asi que ya sabeis queridos compañeros y camarilla friqui, si queremos utilizar CMS pesados y sobrecargados, si nos apetece programar como cerdos sin pensar en las consecuencias de rendimiento, en definitiva, si queremos seguir como hasta ahora… siempre tendremos ahí al amigo Squid para sacarnos las castañas del fuego. Bon apetit ! :D

UPDATE: Tras poner un comentario en WordPress, el Header Location te manda de nuevo al artículo, que como si es cacheable, se pierde la visualización del comentario. Lo he solucionado agregando una regla a squid que evita que se cacheen las urls que contengan «nocache» y modificando la linea 82 de wp-comments-post.php de

wp_redirect($location);

a

$limpiar= (empty($_POST[‘redirect_to’]) ? get_permalink($comment_post_ID) : $_POST[‘redirect_to’]);
exec(‘squidclient -p80 -m PURGE ‘.$limpiar);
exec(‘squidclient -p80 -m PURGE http://www.propiedadprivada.com/’);
session_start();
session_register(«nocache»);
wp_redirect(str_replace(«#»,»?nocache=».$comment_id.»#»,$location));