¿Esta TYPO3 listo para memcached?

Esta claro que memcached es una buena solución para mejorar el rendimiento de las aplicaciones web, prueba de ello es que lo usa Wikipedia, LiveJournal... y un montón mas de grandes webs y empresas, pero ¿esta TYPO3 listo para aprovecharse de memcached?

Desgraciadamente creo que hay que empezar por decir que TYPO3 no esta listo para aprovecharse de las ventas que puede ofrecer memcached, por lo menos hasta la versión 4.1.6 (en breve me centrare en la versión 4.2, pero no creo que cambie mucho en este aspecto).

Esta es la respuesta rápida porque afortunadamente se puede corregir en gran medida este "defecto"

¿Por qué no funciona?

Lo primero que tengo que decir es que las pruebas las he realizado con ADODB, aunque si prescindiese de ADODB el resultado creo que sería el mismo.

Cuando preparamos un SELECT de SQL y lo queremos almacenar en memcached para que su acceso sea más rápido lo que hacemos es calcular un hash MD5 de este SELECT y colocarlo junto con los resultados en la cache de memcached. Cuando volvemos a repetir la consulta volvemos a calcular ese MD5 para buscarlo en la cache y recuperar los datos. El problema es que debido a que muchos de los registros a recuperar tienen campos de fecha y hora que indican desde y hasta cuando están disponibles y que se comparan con la fecha y hora actual  (con una precisión de como mucho 1 segundo). Esta comprobación para ver si un registro esta disponible dentro de una fecha genera consultas SQL únicas en cada instante y por lo tanto es practicamente imposible que podamos recuperar datos de la cache puesto que cada consulta tendrá un MD5 distinto (y el MD5 es el valor hash que se utiliza para buscar datos en memcached). Con tantos fallos de cache puede que TYPO3 de un rendimiento incluso peor que si no empleasemos memcache.

¿Cómo hacer que funcione?

 Hay que modificar las clases que realizan el acceso a base de datos para hacer SELECT (en la capa de persistencia, no entodas las clases que hacen SELECT) y en especial t3lib_page para que no se hagan consultas de este tipo:

 $this->where_hid_del.= 'AND (pages.starttime<='.$GLOBALS['SIM_EXEC_TIME'].') AND (pages.endtime=0 OR pages.endtime>'.$GLOBALS['SIM_EXEC_TIME'].') ';

Para evitar estas consultas podemos reemplazar las llamadas a $GLOBALS['SIM_EXEC_TIME'] por una función propia que redondee la hora dejándola con una precisión de minutos en vez de segundos puesto que no creo que tenga mucha importancia que una página este disponible a las 12:01 o 12:05 cuando habiamos dicho que tendría que estar disponible a las 12:00 si con la pérdida de precisión horaria tenemos un mejor rendimiento de nuestro gestor.

Otra aproximación posible es reemplazar toda esa parte de la consulta SQL y realizarla en dos partes, una sin fecha que traiga todos los datos y otra que compruebe la fecha y que recoja sólo el UID. De esta forma se puede seguir manteniendo la precisión horaria de acceso a los registros, pero es bastante más complicada de implementar

El camino sencillo

Cuando vaya recopilando una serie de mejoras crearé una extensión para que todo esto sea totalmente transparente al usuario y si la gente ve como positivos estos cambios lo ideal sería promoverlos en el core de TYPO3

¿Merece la pena?

Yo creo que sí, si tu sitio necesita escalar para soportar grandes volúmenes de tráfico. Personalmente en alguna de pruebas de  rendimiento en la que la comunicación con la base de datos es el principal cuello de botella he logrado aumentar el rendimiento en el número de conexiones por segundo multiplicándolo por 10

Enviando tu valoracion...

Valorado: 5,0 de 5. 2 voto(s).
Haz click en la barra para valorar el elemento.