GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

Pruebas de Carga con Microsoft WCAT (Web Capacity Analysis Tool) 5.2


Ya sea con la gorra de Desarrollador, o con la de Administrador de Sistemas, la realización de Pruebas de Carga de Aplicaciones Web es una tarea con la que nos interesa familiarizarnos, para poder poner a prueba nuestros Sistemas y Aplicaciones, y comprobar qué nivel de Rendimiento, Escalabilidad y Alta Disponibilidad son capaces de entregarnos. Para todo esto, el presente artículo realiza una introducción a la realización de Pruebas de Carga con Microsoft WCAT (Web Capacity Analysis Tool) 5.2, disponible en el Kit de Recursos de IIS6.

La realización de Pruebas de Carga sobre Aplicaciones Web es una gran herramienta para Desarrolladores y Administradores de Sistemas (y de SharePoint ;-), algo que podemos realizar fácilmente con Microsoft WCAT (Web Capacity Analysis Tool).

Lo primero aclarar que podemos obtener Microsoft WCAT 5.2 como parte del Kit de Recursos de IIS6 (disponible como descarga gratuita), aunque no es necesario ejecutarlo en un servidor Windows Server 2003. Esta es la versión que hemos utilizado durante la elaboración del presente artículo, pero igualmente, también es posible obtener versiones posteriores de Microsoft WCAT descargándolas gratuitamente y de forma independiente.

Por lo tanto, antes de continuar, aclarar que el presente artículo tan sólo pretende ser una introducción a Microsoft WCAT 5.2, con la idea de tener unas nociones muy básicas para poder empezar a utilizarlo, sin mayor ambición. Además, es interesante tener en cuenta que con la instalación del Kit de Recursos de IIS 6.0, además de los ejecutables de WCAT, también se instala un fichero de ayuda que incluye documentación de uso de WCAT y del resto de componente del Kit de Recursos de IIS6.

Introducción a Microsoft WCAT 5.2

Microsoft WCAT está formado principalmente por dos componentes:

  • El Controlador WCAT (wcctl.exe). Es el proceso que coordina la Prueba de Carga, para lo cual, necesita al menos tres ficheros de configuración: config.txt, distribution.txt, y script.txt.
  • Los Clientes WCAT (wcclient.exe). Es el proceso que ejecuta la Prueba de Carga, para lo cual necesita conectarse a un Controlador WCAT especificado como parámetro, el cuál coordinará la prueba. El Cliente WCAT es una Aplicación Multihilo, capaz de crear múltiples hilos para de este modo simular la actividad de múltiples usuarios.

Por poner un caso muy sencillo, podríamos tener una máquina en la cual ejecutásemos el Controlador WCAT y el Cliente WCAT. De este modo, podríamos realizar una Prueba de Carga, sencilla, y quizás suficiente para una gran parte de los casos.

Por poner un ejemplo opuesto, también podríamos tener una máquina en la que ejecutásemos el Controlador WCAT, y además de ésta, podríamos tener ocho máquinas adicionales, en cada una de las cuales ejecutásemos un Cliente WCAT, para de este modo realizar una Prueba de Carga más agresiva.

Ficheros de Configuración del Controlador WCAT: config.txt, script.txt, y distribution.txt

Para poder realizar una Prueba de Carga con Microsoft WCAT, necesitaremos crear los ficheros de configuración del Controlador WCAT. Los principales ficheros son los siguientes:

  • config.txt. Se trata del principal fichero de configuración de WCAT, en el cual, podemos parametrizar la duración de la Prueba de Carga, el tiempo de calentamiento o WarmupTime (tiempo de espera entre el instante en que se unieron todos los clientes y el momento de comienzo del test), el tiempo de enfriamiento o CooldownTime, el número de Clientes WCAT, ó el número de Hilos/Threads/Virtual Clients que deberá abrir cada uno de los Clientes WCAT, por poner algunas de las configuraciones típicas del config.txt.
  • script.txt. Permite parametrizar diferentes navegaciones (llamadas Transacciones), es decir, la secuencia de peticiones HTTP a realizar. Por ejemplo, podríamos parametrizar una Transacción que realice la petición GET de una Home, y seguidamente la petición GET de una sub-página por debajo (ej: simulando un navegador que tiene en Caché el resto de recursos, como imágenes, ficheros JavaScript, Hojas de Estilo CSS, etc.), y también parametrizar una segunda Transacción que realice una petición GET de una Home seguida de una petición GET para cada uno de sus recursos (ej: imágenes, ficheros JavaScript, Hojas de Estilo CSS, etc., simulando un Navegador que tiene vacía la Caché), y finalmente las peticiones GET necesarias para acceder a una sub-página. En el fichero script.txt también tenemos posibilidad de utilizar muchos comandos para parametrizar la navegación, desde especificar unas credenciales de usuario (ej: para realizar una petición a una página Web que requiera autenticación, como es el caso de SharePoint), a otros comandos quizás menos habituales.
  • distribution.txt. Si bien en el fichero de configuración script.txt podemos definir una o varias Transacciones (secuencias de navegación), el fichero distribution.txt es el lugar dónde especificaremos el peso de cada Transacción, es decir, que porcentaje del tiempo de nuestra Prueba de Carga deberá ser empleado por cada Transacción. De este modo, por ejemplo, podríamos tener tres Transacciones, asignando pesos del 70%, 20% y 10%.

A continuación se muestra una pantalla capturada de estos tres ficheros de configuración, para una Prueba de Carga con un único Cliente WCAT que empleará 50 Hilos/Threads, en realizar dos Transacciones con pesos del 10% y 90%. Ambas Transacciones están formadas por peticiones GET autenticadas con usuario y contraseña a un SharePoint 2007.

Pantalla capturada de estos tres ficheros de configuración (config.txt, script.txt, y distribution.txt), para una Prueba de Carga con un único Cliente WCAT que empleará 50 Hilos/Threads, en realizar dos Transacciones con pesos del 10% y 90%. Ambas Transacciones están formadas por peticiones GET autenticadas con usuario y contraseña a un SharePoint 2007

Insisto en la importancia del fichero Script. Por ejemplo, en el anterior screenshot podemos ver cómo configurar correctamente peticiones HTTP con Autenticación NTLM, evitando así que se produzcan errores 401.

Opcionalmente, es posible utilizar un cuarto fichero de configuración indicando los Contadores de Rendimiento que deseemos monitorizar. Sin embargo, esta no resulta una opción interesante, ya que en muchos casos, necesitaremos monitorizar varias máquinas (ej: varios Frontales Web de una Granja) sobre las que estamos ejecutando la Prueba de Carga, y además, podemos necesitar monitorizar otras máquinas y contadores adicionales (ej: Servidores de Aplicaciones, Servidores de Base de Datos, etc.). Por lo tanto, lo más probable es que no nos resulte interesante gestionar la Monitorización de esta forma.

Ejecutando las Pruebas de Carga con WCAT

Ahora que ya tenemos preparados los ficheros de configuración WCAT, podemos empezar la prueba arrancando el Controlador WCAT, por ejemplo, ejecutando un comando como el siguiente: wcctl -a localhost -c config.txt -d distribution.txt -s script.txt

Ahora que ya tenemos preparados los ficheros de configuración WCAT, podemos empezar la prueba arrancando el Controlador WCAT, por ejemplo, ejecutando un comando como el siguiente: wcctl -a localhost -c config.txt -d distribution.txt -s script.txt

El Controlador WCAT se quedará a la espera de que se arranquen TODOS los Clientes WCAT, y sólo entonces, empezará la Prueba de Carga. Mientras tanto, el Controlador WCAT se quedará Waiting.

Así que, realizado esto, deberemos levantar cada uno de los clientes que participen en la prueba. En nuestro caso de ejemplo tenemos un único Cliente WCAT, que físicamente es la misma máquina que el Servidor WCAT y que el Servidor WEB, por lo que ejecutaremos un comando como el siguiente: wcclient.exe localhost

Realizado esto, deberemos levantar cada uno de los clientes que participen en la prueba. En nuestro caso de ejemplo tenemos un único Cliente WCAT, que físicamente es la misma máquina que el Servidor WCAT y que el Servidor WEB, por lo que ejecutaremos un comando como el siguiente: wcclient.exe localhost

Finalizada la prueba, podremos comprobar el fichero LOG generado por el Controlador WCAT, que tendrá un aspecto similar al siguiente.

Finalizada la prueba, podremos comprobar el fichero LOG generado por el Controlador WCAT, que tendrá un aspecto similar al siguiente.

Finalizada la Prueba de Carga, es interesante revisar los LOGs de los Servidores Web afectados (IIS) para comprobar que todo ha ido OK.

Diseñando Pruebas de Carga: No es tan fácil

Hay varios detalles que deberemos tener en cuenta durante el diseño de unas Pruebas de Carga. Quizás lo primero que deberemos considerar, es la Navegación, es decir, la secuencia de peticiones HTTP que deseamos realizar. Por ejemplo, si queremos simular un “usuario nuevo” que no tiene cacheada la Página Web que deseamos probar, entonces incluir las peticiones a la propia Página Web así como las peticiones al resto de recursos (ej: imágenes, ficheros JavaScript, Hojas de Estilo CSS, etc.). Sin embargo, si deseamos simular un “usuario habitual”, que ha accedido anteriormente a la Página Web y la tiene cacheada en su navegador, entonces deberemos incluir sólo la petición para la Página Web (sin incluir el resto de recursos que ya tendrá cacheados). Para ayudarnos a aclarar qué peticiones incluir en la Navegación de nuestra Prueba de Carga, podemos realizar varias Navegaciones de ejemplo y consultar posteriormente los LOGs de IIS, para ver realmente cuáles fueron las peticiones HTTP realizadas en cada caso.

Como consecuencia de lo anteriormente dicho, podríamos evaluar dos Navegaciones (una de “usuario nuevo” y hosra de “usuario habitual”) asignando diferentes pesos a cada navegación (ej: 90% y 10%).

En el caso de estar realizando una Prueba de Carga contra una Granja Web, podemos evaluar realizar una Prueba de Carga contra cada uno de los Frontales Web, así como adicionalmente evaluar una Prueba de Carga contra la URL ó URLs balanceadas.

Del mismo modo, en el caso de estar realizando una Prueba de Carga contra una Granja Web geográficamente distribuida (es decir, con Frontales dispersos entre distintos Centros de Datos), deberemos de considerar la ubicación de los Clientes WCAT frente a la ubicación del Servidor Web a estresar, desde el punto de vista de las comunicaciones. Es decir, el resultado de la prueba podría cambiar dependiendo de que los Clientes WCAT y Servidores Web estén en la misma ubicación (Centro de Datos ó incluso en la misma VLAN), frente a que estén en ubicaciones remotas.

También puede ser interesante repetir la Prueba o Pruebas de Carga bajo diferentes configuraciones, como pueden ser varias configuraciones distintas de Threading en IIS, diferente número de Procesadores o cantidad de Memoria RAM, etc.

Otro tema a tener en cuenta es la monitorización de la Prueba de Carga, es decir, seleccionar qué máquinas y qué Contadores de Rendimiento de cada máquina. Por ejemplo, además de los Frontales Web podemos necesitar monitorizar los Servidores de Base de Datos.

Deberemos considerar la Franja Horaria en la que realizar la Prueba de Carga. La carga de nuestra infraestructura (ej: Red Ethernet, Almacenamiento SAN, infraestructura de virtualización, etc.) puede variar por diferentes motivos (ej: la propia actividad en sí, las tareas de Backup, etc.). En ocasiones, incluso interesa repetir la prueba en diferentes Franjas Horarias, y observar la diferencia en los resultados.

La duración de la Prueba de Carga también es importante. En ocasiones, nos interesará realizar una prueba lo suficientemente larga, como para comprobar a partir de qué punto se empiezan a encolar peticiones, y a partir de qué punto se empiezan a rechazar.

También nos puede afectar la existencia de recursos externos (ej: ficheros JavaScript de servicios de Estadística, Publicidad, etc.), ya que dichos recursos pueden introducir esperas adicionales en nuestra Página Web, tanto por el tiempo adicional de descarga, como por su posterior ejecución en el Navegador del usuario. Situación que deberíamos contemplar dentro de nuestro Plan de Pruebas.

Igualmente, el tiempo de respuesta del usuario también puede verse afectado por la ejecución de ficheros JavaScript, Hojas de Estilo, etc., algo que no podremos simular con Microsoft WCAT, y que puede afectar a la experiencia de usuario, incluso dependiendo del Navegador utilizado.

Y por último, está la interpretación de los resultados. No se trata sólo de ver cuál es la capacidad de nuestros Sistemas o Aplicaciones, sino también de identificar dónde está el cuello de botella.

Despedida y Cierre

En el presente artículo hemos visto una introducción a la herramienta WCAT (Web Capacity Analysis Tool) 5.2, así como también una breve introducción al diseño de Pruebas de Carga, una herramienta que podremos utilizar en muchos casos, como por ejemplo para hacer Pruebas de Rendimiento con distintas configuraciones de Threading (como vimos recientemente en el artículo IIS Deadlocks, Rendimiento, Threads y SharePoint). Antes de finalizar, aprovecho para incluir algunos enlaces de interés.

Por último, tan sólo me queda añadir un ZIP con unos ficheros de configuración de ejemplo, con la idea de que podáis descargarlos y verlos/modificarlos, si lo necesitáis.

Descargar ficheros de ejemplo de configuración WCAT con Autenticación NTLM (Pruebas_Carga_Microsoft_WCAT.zip)

Poco más por hoy. Como siempre, confío que la lectura resulte de interés.

 


[Fecha del Artículo (UTC): 25/07/2013]
[Autor: GuilleSQL]



Escribir un Comentario

Para poder escribir un comentario, debe Iniciar Sesión con un usuario.

Si no dispone de un usuario, puede Registrarse y hacerse miembro.

Si dispone de un usuario, pero no recuerda sus credenciales de acceso, puede Restablecer su Contraseña.

Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Enero de 2017 (4)
Junio de 2016 (1)
Mayo de 2016 (2)
Abril de 2016 (2)
Septiembre de 2015 (2)
Agosto de 2015 (2)
Junio de 2015 (10)
Mayo de 2015 (4)
Abril de 2015 (8)
Marzo de 2015 (11)
Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Esta información se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho.
This information is provided "AS IS" with no warranties, and confers no rights.

Copyright © 2007 GuilleSQL, todos los derechos reservados.
GuilleSQL.com y GuilleSQL.net son también parte de Portal GuilleSQL.

Visitas recibidas (Page Loads) en GuilleSQL (fuente: StatCounter):

screen resolution stats
Visitas