| Tsung | |
|---|---|
| Tipo de | Herramienta de prueba de carga |
| Desarrollador | Nicolás Nicklausse |
| Escrito en | Erlang [1] |
| Interfaz | línea de comando |
| Sistema operativo | linux , unix |
| ultima versión |
|
| Licencia | GNU GPL 2 |
| Sitio web | tsung.erlang-projects.org |
Tsung (del inglés Tsunami-Next Generation [3] , anteriormente conocido como IDX-Tsunami ) es un sistema de pruebas de tensión y carga distribuida escrito en el lenguaje Erlang . El desarrollo del sistema fue iniciado por Nicolas Niclauss e en 2001. Inicialmente, era un sistema distribuido de pruebas de carga jabber para las necesidades internas de IDEALX (ahora OpenTrust ). Unos meses más tarde, el proyecto se convirtió en una herramienta multiprotocolo de código abierto para pruebas de carga. El soporte HTTP se agregó en 2003.
Tsung se puede usar para probar varios protocolos HTTP (incluido SOAP ), WebDAV , Jabber , LDAP , así como PostgreSQL y MySQL , y también permite emular un clúster desde máquinas cliente [4] .
Para el protocolo HTTP , el sistema permite:
Dentro del protocolo Jabber/XMPP , se pueden probar los mensajes de autenticación , el registro de presencia, los mensajes de chat, el trabajo con la lista de usuarios, las salas y la configuración de sincronización de usuarios .
El archivo de configuración de Tsung es un archivo XML . La etiqueta principal es la etiqueta <tsung>que encierra toda la configuración. La etiqueta tiene dos propiedades: loglevel y dumptraffic . loglevel controla la verbosidad del registro, mientras que dumtraffic se usa para la depuración. La opción dumptraffic=true crea un archivo de registro dump.log que detalla cada respuesta del servidor. En la última versión de Tsung, hay opciones dumptrafic=light - los primeros 44 bytes de la respuesta del servidor y dumptrafic=protocol - solo los siguientes datos date;pid;id;http method;host;URL;HTTP status;size;match ; error
<?xml version="1.0"?> <tsung loglevel= "info" dumptraffic= "false" > ... </tsung>Al realizar pruebas, puede utilizar varias direcciones IP virtuales, lo que resulta extremadamente útil cuando el equilibrador de carga del servidor utiliza la dirección de red del cliente para distribuir el tráfico de red en un clúster de servidores.
<clientes> <cliente host= "test1" peso= "1" maxusers= "500" > <ip value= "10.0.2.3" /> <ip value= "10.0.2.4" /> </client> <cliente host = "test2" weight= "3" maxusers= "250" cpu= "2" > <ip value= "10.1.2.5" /> </client> </clients> <server host= "10.2.2.10" port= tipo "8081" = "tcp" />Erlang VM puede ejecutar múltiples núcleos: es más eficiente para los clientes de Tsung usar una VM por núcleo. El parámetro cpu debe ser igual al número de núcleos en los nodos.
En este ejemplo, la segunda máquina se usa en un clúster Tsung con un gran "peso" y dos núcleos. De forma predeterminada, la carga se distribuye uniformemente entre todos los núcleos (un núcleo por cliente de forma predeterminada). El parámetro de peso (entero) se puede utilizar para establecer la prioridad de la máquina cliente. En concreto, si un cliente tiene un peso de 1 y otro tiene un peso de 2, el segundo lanzará el doble de usuarios que el primero (las proporciones serán 1/3 y 2/3). En el ejemplo anterior, donde el segundo cliente tiene cpu=2 y peso=3 , el peso es 1,5 para cada núcleo.
Tsung admite varias opciones de monitoreo: agente de monitoreo nativo en Erlang , Munin o SNMP . El agente debe estar instalado en el lado del servidor [5] . Si la carga se crea para un clúster de servidores, puede usar diferentes agentes para diferentes servidores.
<monitoreo> <monitor host= "10.1.1.94" type= "erlang" /> <monitor host= "10.1.1.94" type= "munin" > <munin port= "8081" /> </monitor> <monitor host = "10.1.1.94" type= "snmp" > <snmp version= "v2" community= "rwCommunity" port= "11161" /> </monitor> </monitoring>La carga se puede dividir en varias fases. En la configuración, puede establecer la duración de cada fase y la secuencia de fases. En cada fase, puede establecer la cantidad de usuarios simultáneos de dos maneras: establezca la cantidad de usuarios por período de tiempo, como 100 usuarios por segundo, o establezca la frecuencia de creación de usuarios, como un usuario cada 0,01 segundos. En una carga estable, puede insertar una sesión específica en un momento determinado para simular algún tipo de verificación o iniciar algún servicio.
<load> <llegadafasefase = "1" duración= "10" unidad= "minuto" > <!-- Fase de calentamiento --> <usuarios entre llegadas= "0.1" unidad= "segundo" > </usuarios> < /arrivalphase > <llegadafasefase = "2" duración= "60" unidad= "minuto" > <!-- Fase de carga --> <users llegadatasa= "1000" unidad= "segundo" > </usuarios> </llegadafase > < !-- Sesiones Especiales --> <user session= "addManyProducts" start_time= "20" unit= "minute" /> <user session= "checkOrders" start_time= "25" unit= "minute" /> </ cargar>El siguiente ejemplo de configuración establece un porcentaje de agentes de usuario para simular diferentes navegadores . Este porcentaje determina la probabilidad de asignar una sesión de usuario a uno de los agentes especificados (el valor predeterminado es asignado - tsung ):
< tipo de opción= "ts_http" nombre= "usuario_agente" > < probabilidad de usuario_agente= "60" > Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20100101 Firefox/9.0 </usuario_agente> <usuario_agente probabilidad= "20" > Mozilla/5.0 (compatible; MSIE 8.0; Windows NT 5.0; Trident/4.0; InfoPath.1; SV1; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET CLR 3.0.04506.30) </usuario_agente> <usuario_agente probabilidad= "20" > Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.21 (KHTML, como Gecko) Chrome/19.0.1042.0 Safari/535.21 </usuario_agente> </opción>