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.
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
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
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.
Poco más por hoy. Como siempre, confío que la lectura resulte de interés.
