Después de un tiempo de no escribir, encontré un tema para volver al blog.
Estoy haciendo stress tests sobre un nuevo server para mi cliente, el que tiene Windows Server 2008 R2, que es x64 y hasta donde se no tiene version 32 bit.
Hasta hace poco usaba WAST (Web Application Stress Tool) una herramienta relativamente vieja para stress tests, pero que para lo que necesitaba probar, funcionaba decentemente. Ahora empecé a usar WCAT (Web Capacity Analysis Tool), herramienta que tiene versión de 32 y de 64 bit, y que funciona completamente diferente que WAST.
En éste artículo explican como hacer para que, a partir de los logs de IIS, se pueda generar la prueba, con las mismas características que la carga que tenía cuando se generó ese log.
Este método de generación de tests es una de las ventajas de WAST ya que directamente importa el log y se ejecuta directamente desde la interface de usuario.
En WCAT, existen varios componentes de software que intervienen en la prueba, sin embargo, no todos ellos son requeridos para hacer una, y los que son requeridos pueden ejecutarse en una sola máquina, aunque no está recomendado.
En el artículo, figuran los links a los componentes de software usados durante la instalación, pero solamente tres archivos fueron creados por el autor
http://theether.net/download/Microsoft/IIS/wcat.sql
http://theether.net/download/Microsoft/IIS/wcat.tpl
http://theether.net/download/Microsoft/IIS/wcat.NTLM.tpl
Estos tres archivos son el core de la integración de los productos WCAT y LogParser
El primero (wcat.sql) de los tres tiene el siguiente texto:
SELECT
OUT_ROW_NUMBER() as ID,
STRCAT(cs-uri-stem,
REPLACE_IF_NOT_NULL(cs-uri-query,
STRCAT('?',realQueryString))) AS URI,
count(*) AS WEIGHT,
case sc-status
when 304 then 200
when 206 then 200
else sc-status end as STATUSCODE
using
extract_token(cs-uri-query,0,'') as realQueryString
INTO %outfile%
FROM %logfile%
WHERE
cs-method = 'GET' and STATUSCODE = 200
GROUP BY URI, STATUSCODE
ORDER BY WEIGHT DESC
Este texto corresponde a una consulta para LogParser 2.2 en el que se formatea un log de IIS generando un result set con cuatro campos, ID, URL, WEIGHT y STATUSCODE generando un archivo de salida
El segundo (wcat.tpl) archivo tiene el siguiente texto
<LPHEADER>
scenario
{
name = "Generated Using Log Parser";
warmup = 30;
duration = 120;
cooldown = 10;
default
{
setheader
{
name = "Host";
value = "intranet";
}
setheader
{
name = "Connection";
value = "keep-alive";
}
setheader
{
name = "User-Agent";
value = " Mozilla/4.0 (compatible; MSE 6.0; Windows NT 5.1; SV1)";
}
version = HTTP11;
close = ka;
}
</LPHEADER>
<LPBODY>
transaction
{
id = "URL %ID%";
weight = %WEIGHT%;
request
{
url = "%URI%";
statuscode = %STATUSCODE%;
}
}
</LPBODY>
<LPFOOTER>
}
</LPFOOTER>
El tercero (wcat.NTLM.tpl) de los archivos tiene este texto
<LPHEADER>
scenario
{
name = "Generated Using Log Parser";
warmup = 30;
duration = 120;
cooldown = 10;
default
{
setheader
{
name = "Host";
value = "intranet";
}
setheader
{
name = "Connection";
value = "keep-alive";
}
setheader
{
name = "User-Agent";
value = " Mozilla/4.0 (compatible; MSE 6.0; Windows NT 5.1; SV1)";
}
version = HTTP11;
close = ka;
}
</LPHEADER>
<LPBODY>
transaction
{
id = "URL %ID%";
weight = %WEIGHT%;
request
{
url = "%URI%";
statuscode = 401;
}
request
{
url = "%URI%";
authentication = NTLM;
username = "DOMAIN\\user";
password = "password";
statuscode = %STATUSCODE%;
}
}
</LPBODY>
<LPFOOTER>
}
</LPFOOTER>
Los dos últimos archivos son Templates (TPL) de LogParser con el que se da formato a los datos de salida de la consulta el primero de ambos está pensado para acceso anónimo al servidor y el segundo usando autenticación NTLM.
Para los tests que tengo que hacer ahora no necesito autenticación con el Web Server entonces elijo los dos primeros, si tuviera que hacer autenticación con IIS, elegiría el primero y el último.
Lo que hago entonces ahora es, tal como dice el artículo referenciado más arriba, es usar LogParser para generar los archivos de test de WCAT usando los datos que están en el log. Para eso ejecuto el siguiente comando (tomado del artículo)
Logparser file:WCat.sql?logfile=*.log+outfile=CurrentLog.ubr -i:IISW3C -o:tpl -tpl:WCat.tpl
Esta linea de comandos asume que los archivos que usa de entrada (en este caso WCat.tpl y WCat.sql están en el directorio presente (Current Directory) en el momento de la ejecución y que LogParser o bien está en el mismo directorio presente o en el PATH.
A continuación voy a describir el comando de logparser que va a generar el archivo de entrada para entenderlo mejor.
El primer parámetro es:
file:<query_filename>[?param1=value1+...]
en el que query_filename es WCat.sql y los parámetros son logfile y outfile, que son usados en el INTO y en el FROM del primer texto, lo que nos indica que los archivos también tienen que estar en el mismo directorio presente. También vemos que el archivo resultante en este comando se llama CurrentLog.ubr. Esto es muy importante porque este archivo es el que vamos a usar en WCAT.
El segundo parámetro es:
-i:<input_format>
En éste parámetro vemos que estamos diciéndole a LogParser que el log que estamos pasándole como entrada es de IIS.
El tercer parámetro es:
-o:<output_format>
Aquí le pedimos a LogParser que nos entregue su salida usando un template (tpl).
El cuarto parámetro es:
-tpl:MyTemplate.tpl
Este parámetro indica a LogParser que use el archivo WCat.tpl como template para producir la salida.
En caso de necesitar usar el template que tiene la autenticación NTLM usaríamos la siguiente línea de comandos.
Logparser file:WCat.sql?logfile=*.log+outfile=CurrentLog.ubr -i:IISW3C -o:tpl -tpl:WCat.NTLM.tpl
Todo este proceso de generación puede ser ejecutado en cualquier equipo que tenga instalado LogParser 2.2.
A partir de ahora comenzaremos a usar WCAT.
WCAT tiene, como ya digimos, varios componentes, de los cuales solo dos son requeridos para su ejecución: el controlador y el cliente.
Una vez instalado WCAT en el equipo que fungirá de controlador, para instalar los clientes debemos ejecutar un comando, desde éste equipo, que instala en los equipos cliente el software necesario para el funcionamiento de WCAT en estos equipos. Si este software es instalado por primera vez, el equipo se reiniciará a continuación de la instalación.
El controlador de WCAT es la pieza de software que, valga la redundancia, controlará la ejecución y la configuración de las pruebas.
Un cliente es un equipo que hará las peticiones HTTP al servidor tal como el controlador le indique.
Puede haber más de un cliente pero no más de un controlador.
Para configurar los clientes se ejecuta un script de WSH.
cscript wcat.wsf –terminate -update -clients localhost Test1
en donde wcat.wsf es el script de configuración, –terminate indica que si hubiera ya configurados clientes, los mismos deben ser detenidos si estuvieran corriendo, –update indica que se van a modificar los datos de configuración, –clients indica la lista de clientes en la que se debe instalar el software de cliente. Esta instalación producirá que los clientes en los que nunca se haya instalado el software se reinicien.
Una vez configurado, debemos iniciar el controller y los clientes, para iniciar el controller ejecutamos
wcctl.exe -t currentlog.ubr -s webserver.domain.com -c 2 -v 500
en donde:
-clien(t)file file Scenario file sent to client.
-(s)erver string Comma delimited list of remote servers
-(c)lients number Number of expected client connections.
-(v)irtualclients number Number of virtual clients to use.(directo de la documentacion de WCAT)
para iniciar los clientes ejecutamos
wcclient.exe controller.domain.com
Finalmente, confieso que todavia no hice las pruebas el día de hoy, solo leí el artículo y la documentación tanto de LogParser como de WCAT y comenzaré a hacer las pruebas ahora. Seguramente haré algún otro post respecto de mis pruebas.
0 comentarios:
Publicar un comentario