Rendimiento en aplicaciones PHP

22/10/2009

En esta última semana he comenzado a participar en un nuevo proyecto. Consiste en hacer una auditoría del rendimiento y la calidad del software de una aplicación implementada con tecnología PHP. El problema está en que la aplicación va degradando el servidor de aplicaciones web Apache hasta que este provoca una denegación de servicio y es preciso reiniciarlo.

Para esta auditoría se van a utilizar diversas herramientas:

1. Análisis del rendimiento de la aplicación web. En esta parte se localizarán los cuellos de botella en tiempo de ejecución y en definitiva los motivos por los cuales la aplicación consigue degradar el servidor hasta el punto de hacer que provoque la denegación de servicio antes comentada. Para ello se van a utilizar dos herramientas, The Grinder y XCacheGrind.

  • The Grinder. Me la recomendó mi compañero Antonio, y es simplemente espectacular. Es una herramienta basada software libre y su funcionamiento e instalación es muy simple, está basado en una consola central y en uno o varios agentes, cada uno de estos agentes (que son distribuidos entre distintas máquinas físicas) despliega una serie de workers y cada uno de estos workers despliega los hilos que los agentes tengan configurados. Además proporciona un proxy que nos permite realizar las pruebas UI fácilmente con cualquier navegador.
Esquema de funcionamiento de The Grinder

Esquema de funcionamiento de The Grinder

  • XCacheGrind. Esta herramienta tiene dos variantes WinCacheGrind y KCacheGrind y permiten visualizar gráficamente el consumo de tiempo que cada una de las funciones o scripts PHP ha tardado en ejecutarse y otra información que puede ser de interés para realizar las tareas de profile. Para ello hace uso de los logs que proporciona XDebug, que se tendrán que configurar con los siguientes parámetros:

xdebug.remote_autostart = On
xdebug.remote_enable=On
xdebug.profiler_output_dir = “/home/aclr/kcachegrind/”
xdebug.trace_output_dir = “/home/aclr/kcachegrind/”
xdebug.profiler_append = On
xdebug.profiler_enable = On
xdebug.auto_trace = On

Veamos un ejemplo de la información que obtenemos haciendo uso de estas herramientas:

<?php
function escribe($cad){
echo $cad.'<br/>’;
}

for($i = 0 ; $i < 100 ; $i++){
for($j = 0; $j < 100 ; $j++){
escribe(“hola”);
}
}
?>

Distribución de la ejecución

Como se puede apreciar en esta imagen solo el 9.6% del tiempo consumido en la ejecución es utilizado por la función escribe, el resto, el 99.4% del tiempo de ejecución se ejecuta en el main, es decir, en el bucle, en un caso real una situación análoga a esta nos diría que tenemos que tratar de centrar nuestros esfuerzos de optimización en el main, no en la función escribe.

En próximas entradas intentaré hablar un poco más en profundidad de The Grinder y sobre las herramientas que se utilizarán para el análisis de la calidad del código.

Aunque me gusta terminar mis posts con la cita de alguna frase célebre que trate o evoque sobre el tema del que versa el post, esta vez voy no podrá ser, son las 2:04 y me voy a la cama 😉


Comunidad y software libre

12/10/2009

El otro día estaba hablando con una buena amiga de la facultad sobre su proyecto fin de carrera, se trata de un portal web implementado con tecnología Drupal, me preguntaba si conocía algún tipo de software, libre, para hacer pruebas de usabilidad, la verdad que me quedé un poco a cuadros, ya que no tenía idea de qué contestarle.

Cuando llegué a mi casa al curiosidad me pudo y me puse a buscar información acerca de este tema, tras un rato empecé a vislumbrar que para la realización de las pruebas de usabilidad existen dos tipos de herramientas, las herramientas de eyetracking y las herramientas de clicktracking. Mientras que las primeras, las más avanzadas, se basan en recoger dónde mira el ojo cuando está visualizando la información, las segundas recogen dónde ha hecho click el ratón en la página html, ambas, sin embargo, muestran los resultados de una forma muy parecida, utilizando heatmaps.

Ejemplo de heatmap

Ejemplo de heatmap

El siguiente paso fue buscar herramientas que proporcionaran las funcionalidades de las que hablaba antes, cuál fue mi sorpresa cuando de repente veo que existe un módulo de Drupal que permite mostrar heatmaps integrándose con la librería de la herramienta ClickHeat.

Estas son las cosas que a uno le hacen pensar y plantearse cosas. La oferta de gestores de contenidos de software libre es amplísima, Drupal, OpenCms, Joomla, Mambo, Magnolia y un largo etcétera, pero a la hora de elegir uno en ¿qué parámetros debemos basarnos?, pueden ser muchos, rendimiento, escalabilidad, curva de aprendizaje, etc, pero para mí uno indispensable es la comunidad de usuarios que haya alrededor del cms en cuestión, una comunidad activa que ayude a través de foros, faq´s, listas de correos, etc, una comunidad que desarrolle y comparta sus desarrollos.

En mi experiencia con los gestores de contenidos he tenido la oportunidad de trabajar con dos de ellos, OpenCms y Drupal. Independientemente de la tecnología, arquitectura, etc utilizada en cada uno de ellos hay una diferencia entre ellos que veo sumamente clara, y es la comunidad, mientras que en Drupal tenemos una activa comunidad con más de 300 módulos desarrollados, compatibles con la versión 6 del gestor de contenidos, en OpenCms es complicado si quiera encontrar una décima parte de esos módulos.

¿Por qué en una comunidad autónoma, como la nuestra, en la que se ha hecho y se sigue haciendo una apuesta tan fuerte por el software libre son tan pocas las empresas proveedoras que siguen este enfoque y se convierten en meras consumidoras de software libre?

Como he citado en otras ocasiones:

El software es como el sexo, es mejor cuando es libre. Linus Torvalds