En el desarrollo de aplicaciones contra bases de datos, la mayoría de las veces, necesitas unos valores de referencia para saber si las consultas o instrucciones que está procesando tu aplicación se están comportando como debiere. También si te toca administrar un servidor de bd y monitorearlo este post te será de gran ayuda.

En este sentido escribiré algunos de los parámetros que podemos monitorear para el caso de bases de datos MySQL.

Básicamente MySQL nos proporciona una serie de instrucciones SQL que nos devuelve información de estado y rendimiento del servidor, para que luego las evaluemos y decidamos que acción pertinente se lleva a cabo.

La instrucción básica que se usa en MySQL es

SHOW STATUS;

la cual nos devuelve una cantidad importante de estados de variables. Aquí explico las más importantes.

Threads_connected

Esta variable indica el número total de clientes que tienen una conexión abierta actualmente con el servidor.
Proporciona información en tiempo real de cuantos clientes están conectados con el servidor. Esto puede ser de ayuda para analizar el tráfico o decidir cuando es el mejor instante para reiniciar un servidor.

Created_tmp_disk_tables

Esta variable indica el número de tablas temporales que han sido creadas en disco frente a hacerlo en memoria.
El acceso a tablas en disco normalmente es más lento que acceder a ellas en memoria. Por tanto las consultas que usan la sintaxis CREATE TEMPORARY TABLE son más lentas si el valor de la esta variable es superior.

Read the rest of this entry »

Muchas veces cuando estas en las fases de pruebas, y cuando tu aplicación se supone que va a soportar grandes flujos de peticiones, querrías testear la misma antes de ponerla en producción.

Como es lógico, estas pruebas sería materialmente imposible hacerlas uno mismo, ya que seríamos incapaces manualmente de generar suficientes peticiones como para saber los límites de rendimiento de nuestros proyectos.
Para esto hay utilidades que ya no solo podemos testear aplicaciones con Rails, si no también cualquier aplicación web escrita en el lenguaje de tu elección.

Aplicaciones de stress

Entonces, desechada la opción de enviarle un mail a todos tus familiares y conocidos para que prueben la app. Vamos a echar un ojo al mundo del software libre para ver los recursos que nos brinda:

JMeter

JMeter aunque un tanto engorroso de configurar, es un gran aliado. Después de trabajar un poco con el se entiende bastante bien y se llega a aprovechar mucho su uso. Además permite trabajar como proxy HTTP para capturar las solicitudes y repetirlas

ab – Apache HTTP server benchmarking tool

ab permite realizar múltiples peticiones GET o POST contra un servidor. Las peticiones las podemos hacer en modo secuencial o, como a nosotros nos interesa en esta ocasión, de modo concurrente, de la misma forma que podemos hacer que las peticiones sean independientes o de forma que esten en la misma sesión.

httperf

Este proyecto tiene muchas opciones para “machacar” a los servidores, donde puedes simular “ráfagas” de “usuarios” conectados de forma concurrente, simula muy bien las sesiones al estilo de los navegadores HTTP actuales.

Además las estadísticas que reporta son muy completas, donde podemos ver porcentaje de uso de CPU, tiempos de respuesta y muchas más cosas.

Autobench

Esta es una abstracción de httpref, no es más que un script escrito en Perl para automatizar la medición del comportamiento. Es básicamente incrementar el número de peticiones o nivel de concurrencia conforme pase el tiempo y analizar cambios bruscos en las peticiones.
El nivel de detalle de este llega al punto de crear gráficas, geniales para su mejor lectura.

En todos los casos tienes que buscarte un poco la vida y trabajar un poco el * –help, ya que la documentación es mas bien escasa, yo empezaría por estudiarte la RFC2616 – HTTP/1.1 Specification.

En definitiva, y bajo mi punto de vista Autobench está muy bien por la utilidad de las gráficas, y para todo lo demás httperf se comporta muy bien.

Recientemente ha salido Ruby on Rails versión 2 que todavía estoy estudiando para llevar a cabo un review. Pero ahora mismo voy a mostrar unos pequeños benchmarks de Ruby 1.9, versión recién salida del horno, y que por lo que parece los se va acercando a lenguajes más “enterprise”.

Pero vayamos al meollo de la cuestión, inicialmente había pensado en crearme alguna función que cargue el sistema de procesos pero como soy un Vago Bueno™, he deducido que el Makefile del intérprete de Ruby tenía que tener algún sistema de benchmark.

Descargaremos la nueva versión 1.9.0 y compilaremos como siempre ./configure && make && make test && make install. Así que lanzaremos lo siguiente:

make benchmark

Esta tarea detectará tu versión anterior y ejecutará un elevado número de pruebas comparando la versión recién compilada con la antigua, he aquí un ejemplo que se lleva a cabo.

vm1_rescue

i=0
while i<30000000 # while loop 1
  i+=1
  begin
  rescue
  end
end

ruby 1.8.6 (2007-09-24) [universal-darwin9.0]    11.3471548557281
ruby 1.9.0 (2007-12-25 revision 14709) [i686-darwin9.1.0]    1.78452610969543

La mejora es evidente, también es verdad que en algunos casos la mejora no es tan sustancial y en otras contadas ocasiones incluso empeora la anterior marca de tiempo. Si queréis ver el reporte completo de mis pruebas os dejo aquí el archivo Benchmarks de Ruby 1.9

Para aquel que esta más interesado en hacer benchmarks de sus scripts, es bueno utilizar la clase Benchmark, que da muchísimas facilidades para llevar a cabo pruebas de forma muy rápida.

Ahora solo falta que el amado/odiado ActionPack de Ruby on Rails soporte MultiThreading para que volemos. Aunque me está gustando el proyecto Merb, que a costa de perder alguna mágia este si que es multithread y ya no corre… vuela.

Por cierto que si estás interesado en benchmarks más generales y más fidedignos pasate por esta review.