La descripción encontrada en wikipedia de “profiling”:
Un “profiler” es una herramienta de análisis de performance que mide el comportamiento del programa mientras este está corriendo, particularmente la frecuencia y duración de las llamadas a funciones. La salida es un rastro (stream) de eventos o un sumario estático de los eventos observados (un “profile”, perfil o reseña). Los profilers usan una amplia variedad de técnicas para recolectar datos, incluyendo interrupciones por hardware, instrumentos de código, ganchos (hooks) del sistema operativo.
El uso de profilers es usado en el proceso de ingeniería de performance. Un profile generalmente es realizado relacionado la posición del código fuente donde suceden los eventos y el tamaño de las medidas de los datos que es proporcional al tamaño del código del programa. En contraste, el tamaño de un rastro es proporcional al tiempo de ejecución de un programa, haciéndolo impracticable. Para programas secuenciales, un profile, es generalmente suficiente, pero los problemas de pefrormance en programas paralelos (que esperan mensajes o temas de sincronismo) generalmente depende del tiempo de relación de los eventos, de esta forma requieren la localización total para tener un entendimiento del problema
Para ello tenemos que instalar php5-xdebug:
sudo aptitude install php5-xdebug
Una vez instalado el módulo Xdebug tenemos que editar su fichero de configuración que encontraremos en:
/etc/php5/apache2/conf.d/xdebug.ini
En ese fichero agregaremos las siguientes lineas:
xdebug.profiler_enabled = 1
xdebug.profiler_output_dir = (path de salida) “/home/usuario/tmp/”
xdebug.profiler_output_name = cachegrind.out. %R
Tras reiniciar el apache comprobaremos en un fichero php el resultado de phpinfo() para comprobar que el modulo xdebug está operativo.
Más parámetros de configuración: xdebug profiler
Al poner %R en el nombre de salida conseguimos que si estamos analizando el domonio localhost guarde los ficheros como: cachegrind.out.localhost
Para conocer más opciones de parametrización de xdebug.profiler_output_name en: http://www.xdebug.org/docs/all_settings#trace_output_name
De esta manera conseguimos que se vayan creando los ficheros que después leeremos con KCachegrind.
Instalamos Kcachegrind:
sudo aptitude kcachegrind kcachegrind-converters
Ahora solo tendremos que lanzar el programa Kcachegrind y abrir el fichero cachegrind.out.localhost. En el mismo directorio encontraremos más ficheros pero tenemos que abrir el fichero principal que es el que no tiene concatenado a su nombre con un punto una secuencia numérica.
El programa analizará los logs de xdebug y nos lo mostrará con una interfaz gráfica intuitiva y no muy complicada de entender:
De esta manera podremos analizar si nuestra aplicación web pierde mucho tiempo en algún proceso en el que no hayamos reparado con anterioridad, el uso de memoria y las llamadas que se realizan a funciones y/o métodos.
Esta configuración está pensada para probarla en la máquina local de desarrollo, en ese caso en el path de salida que hemos configurado en el xdebug.ini tenemos que asignarle los permisos necesarios para que el usuario de apache www-data pueda escribir los logs.
Una vez finalizado su uso, es recomendable desactivar el profile de xdebug para que no nos sature de logs a los que no vamos a hacer caso.
Aunque el pantallazo es de un entorno KDE esta configuración y software se ha realizado en: Ubuntu 9.04 Gnome.
Si tu entorno de desarrollo es Windows, también puedes activar el módulo php_xdebug.dll en tu php.ini y seguir los mismos parámetros de configuración en tu fichero php.ini. Como herramienta para examinar los logs del profile xdebug puedes utilizar WinCacheGrind.
Espero que os sea de utilidad, si conocéis alguna herramienta y/o utilidad que os facilite la tarea de realizar aplicaciones ligeras agradecería el comentario.
me fue imposible utilizar vmware y estuve utilizando qemu pero no me acabó de convencer demasiado, tal vez la versión más actual de qemu tenga un interfaz de usuario más cómoda.
