1.0.4 Comencemos ¶

La forma más fácil de comenzar a usar JMeter es descargar primero la última versión de producción e instalarla. La versión contiene todos los archivos que necesita para crear y ejecutar la mayoría de los tipos de pruebas, por ejemplo, Web (HTTP/HTTPS), FTP, JDBC, LDAP, Java, JUnit y más.

Si desea realizar pruebas de JDBC, necesitará, por supuesto, el controlador JDBC adecuado de su proveedor. JMeter no viene con ningún controlador JDBC.

JMeter incluye el jar de API JMS, pero no incluye una implementación de cliente JMS. Si desea ejecutar pruebas de JMS, deberá descargar los archivos jar apropiados del proveedor de JMS.

A continuación, inicie JMeter y consulte la sección Creación de un plan de prueba de la Guía del usuario para familiarizarse con los conceptos básicos de JMeter (por ejemplo, agregar y eliminar elementos).

Por último, consulte la sección correspondiente sobre cómo crear un tipo específico de plan de prueba. Por ejemplo, si está interesado en probar una aplicación web, consulte la sección Creación de un plan de prueba web . Las otras secciones específicas del Plan de prueba son:

• Plan de prueba web avanzado
• JDBC
• FTP
• JMS punto a punto
• Tema JMS
• LDAP
• LDAP extendido
• Servicios web (SOAP)

Una vez que se sienta cómodo con la creación y ejecución de planes de prueba de JMeter, puede examinar los diversos elementos de configuración (temporizadores, escuchas, aserciones y otros) que le brindan más control sobre sus planes de prueba.

1.1.1 Versión Java ¶

Debido a que JMeter usa solo API estándar de Java, no presente informes de errores si su JRE no puede ejecutar JMeter debido a problemas de implementación de JRE.

1.1.2 Sistemas operativos ¶

JMeter es una aplicación 100% Java y debería ejecutarse correctamente en cualquier sistema que tenga una implementación compatible con Java.

Los sistemas operativos probados con JMeter se pueden ver en esta página en la wiki de JMeter.

Incluso si su sistema operativo no figura en la página wiki, JMeter debería ejecutarse siempre que la JVM sea compatible.

1.2.1 Compilador Java ¶

Si desea compilar la fuente de JMeter o desarrollar complementos de JMeter, necesitará un JDK 8 o superior totalmente compatible.

1.2.2 Analizador SAX XML ¶

JMeter viene con el analizador XML Xerces de Apache . Tiene la opción de decirle a JMeter que use un analizador XML diferente. Para hacerlo, incluya las clases para el analizador de terceros en el classpath de JMeter y actualice el archivo jmeter.properties con el nombre de clase completo de la implementación del analizador.

1.2.3 Soporte por correo electrónico ¶

JMeter tiene amplias capacidades de correo electrónico. Puede enviar correos electrónicos en función de los resultados de las pruebas y tiene un muestreador POP3(S)/IMAP(S). También tiene un muestreador SMTP(S).

1.2.4 Cifrado SSL ¶

Para probar un servidor web usando encriptación SSL (HTTPS), JMeter requiere que se proporcione una implementación de SSL, como es el caso con Sun Java 1.4 y superior. Si su versión de Java no incluye soporte SSL, entonces es posible agregar una implementación externa. Incluya los paquetes de cifrado necesarios en el classpath de JMeter . Además, actualice system.properties para registrar el proveedor de SSL.

JMeter HTTP tiene por defecto el nivel de protocolo TLS. Esto se puede cambiar editando la propiedad de JMeter https.default.protocol en jmeter.properties o user.properties .

Los muestreadores HTTP de JMeter están configurados para aceptar todos los certificados, ya sean de confianza o no, independientemente de los períodos de validez, etc. Esto es para permitir la máxima flexibilidad en las pruebas de servidores.

Si el servidor requiere un certificado de cliente, se puede proporcionar.

También está el SSL Manager , para un mayor control de los certificados.

El muestreador SMTP puede usar opcionalmente un almacén de confianza local o confiar en todos los certificados.

1.2.5 Controlador JDBC ¶

Deberá agregar el controlador JDBC del proveedor de su base de datos a la ruta de clase si desea realizar pruebas de JDBC. Asegúrese de que el archivo sea un archivo jar, no un zip.

1.2.6 Cliente JMS ¶

JMeter ahora incluye la API de JMS de Apache Geronimo, por lo que solo necesita agregar los archivos JMS de implementación del cliente adecuados del proveedor de JMS. Consulte su documentación para obtener más detalles. También puede haber alguna información en JMeter Wiki .

1.2.7 Bibliotecas para ActiveMQ JMS ¶

Deberá agregar el jar activemq-all-XXXjar a su classpath, por ejemplo, almacenándolo en el directorio lib/ .

Consulte la página de configuración inicial de ActiveMQ para obtener más detalles.

1.4.1 Classpath de JMeter ¶

JMeter encuentra automáticamente clases de jars en los siguientes directorios:

JMETER_INICIO/lib

utilizado para tarros de utilidad

JMETER_HOME/lib/ext

utilizado para componentes y complementos de JMeter

Si ha desarrollado nuevos componentes de JMeter, debe colocarlos en un contenedor y copiar el contenedor en el directorio lib/ext de JMeter . JMeter encontrará automáticamente los componentes de JMeter en cualquier contenedor que se encuentre aquí. No use lib/ext para archivos jar de utilidades o archivos jar de dependencia usados ​​por los complementos; solo está destinado a componentes y complementos de JMeter.

Si no desea colocar archivos jar de complementos de JMeter en el directorio lib/ext , defina la propiedad search_paths en jmeter.properties .

Los archivos jar de utilidades y dependencias (bibliotecas, etc.) se pueden colocar en el directorio lib .

Si no desea colocar dichos archivos jar en el directorio lib , defina la propiedad user.classpath o plugin_dependency_paths en jmeter.properties . Vea a continuación una explicación de las diferencias.

Otros archivos jar (como JDBC, implementaciones JMS y cualquier otra biblioteca de soporte que necesite el código JMeter) deben colocarse en el directorio lib , no en el directorio lib/ext , o agregarse a user.classpath .

También puede instalar archivos Jar de utilidad en $JAVA_HOME/jre/lib/ext , o puede establecer la propiedad user.classpath en jmeter.properties

Tenga en cuenta que establecer la variable de entorno CLASSPATH no tendrá ningún efecto. Esto se debe a que JMeter se inicia con " java -jar ", y el comando java ignora silenciosamente la variable CLASSPATH y las opciones -classpath / -cp cuando se usa -jar .

1.4.2 Crear un plan de prueba a partir de una plantilla ¶

Tiene la capacidad de crear un nuevo plan de prueba a partir de una plantilla existente.

Para ello utilice el menú Archivo  →  Plantillas… o el icono Plantillas:

Aparece una ventana emergente, luego puede elegir una plantilla entre la lista:

Algunas plantillas pueden necesitar la entrada de parámetros por parte del usuario. Para estos, después de hacer clic en el botón Crear, aparecerá una nueva ventana de la siguiente manera:

Cuando haya terminado con los parámetros, haga clic en el botón Validar y se creará la plantilla.

Una documentación para cada plantilla explica qué hacer una vez que se crea el plan de prueba a partir de la plantilla.

1.4.3 Usando JMeter detrás de un proxy ¶

Si está probando detrás de un firewall/servidor proxy, es posible que deba proporcionar a JMeter el nombre de host y el número de puerto del firewall/servidor proxy. Para hacerlo, ejecute el archivo jmeter[.bat] desde una línea de comando con los siguientes parámetros:

-MI

[esquema de proxy a usar - opcional - para no http]

-H

[nombre de host del servidor proxy o dirección IP]

-PAGS

[puerto del servidor proxy]

-NORTE

[hosts no proxy] (por ejemplo, *.apache.org|localhost )

-tu

[nombre de usuario para la autenticación de proxy, si es necesario]

-a

[contraseña para la autenticación de proxy, si es necesario]

jmeter -E https -H my.proxy.server -P 8000 -u nombre de usuario -una contraseña -N localhost

También puede usar --proxyScheme , --proxyHost , --proxyPort , --username y --password como nombres de parámetros

Si se proporciona el esquema de proxy, JMeter establece las siguientes propiedades del sistema:

• http.proxyScheme

Si se proporcionan el host y el puerto del proxy, entonces JMeter establece las siguientes propiedades del sistema:

• http.proxyHost
• http.proxyPort
• https.proxyHost
• https.proxyPort

El usuario y la contraseña utilizados para un proxy pueden ser proporcionados por las propiedades del sistema http.proxyUser y http.proxyUser . Serán anulados por los argumentos o valores anteriores establecidos en las Muestras HTTP.

Si se proporciona una lista de hosts que no son proxy, JMeter establece las siguientes propiedades del sistema:

• http.nonProxyHosts
• https.nonProxyHosts

Entonces, si no desea configurar proxies http y https, puede definir las propiedades relevantes en system.properties en lugar de usar los parámetros de la línea de comandos.

La configuración de proxy también se puede definir en un plan de prueba, utilizando la configuración de valores predeterminados de solicitud HTTP o los elementos de muestra de solicitud HTTP .

1.4.4 Modo CLI (el modo Línea de comandos se denominó modo NO GUI) ¶

Para las pruebas de carga, debe ejecutar JMeter en este modo (sin la GUI) para obtener resultados óptimos. Para ello, utilice las siguientes opciones de comando:

-norte

Esto especifica que JMeter se ejecutará en modo cli

-t

[nombre del archivo JMX que contiene el plan de prueba].

-l

[nombre del archivo JTL para registrar los resultados de la muestra].

-j

[nombre del archivo de registro de ejecución de JMeter].

-r

Ejecute la prueba en los servidores especificados por la propiedad JMeter " remote_hosts "

-R

[lista de servidores remotos] Ejecute la prueba en los servidores remotos especificados

-gramo

[ruta al archivo CSV] generar solo el panel de informes

-mi

generar panel de informes después de la prueba de carga

-o

carpeta de salida donde generar el panel de informes después de la prueba de carga. La carpeta no debe existir o estar vacía

La secuencia de comandos también le permite especificar la información opcional del firewall/servidor proxy:

-H

[nombre de host del servidor proxy o dirección IP]

-PAGS

[puerto del servidor proxy]

jmeter -n -t mi_prueba.jmx -l log.jtl -H mi.proxy.servidor -P 8000

Si la propiedad jmeterengine.stopfail.system.exit se establece en verdadero (el valor predeterminado es falso ), entonces JMeter invocará System.exit(1) si no puede detener todos los subprocesos. Normalmente esto no es necesario.

1.4.5 Modo Servidor ¶

Para pruebas distribuidas , ejecute JMeter en modo servidor en los nodos remotos y luego controle los servidores desde la GUI. También puede usar el modo CLI para ejecutar pruebas remotas. Para iniciar los servidores, ejecute jmeter-server[.bat] en cada host de servidor.

La secuencia de comandos también le permite especificar la información opcional del firewall/servidor proxy:

-H

[nombre de host del servidor proxy o dirección IP]

-PAGS

[puerto del servidor proxy]

servidor-jmeter -H mi.proxy.servidor -P 8000

Si desea que el servidor se cierre después de ejecutar una única prueba, defina la propiedad de JMeter server.exitaftertest=true .

Para ejecutar la prueba desde el cliente en modo CLI, use el siguiente comando:

jmeter -n -t testplan.jmx -r [-Gprop=val] [-Gglobal.properties] [-X]

-GRAMO

se utiliza para definir las propiedades de JMeter que se establecerán en los servidores

-X

significa salir de los servidores al final de la prueba

-Rservidor1,servidor2

se puede usar en lugar de -r para proporcionar una lista de servidores para comenzar. Anula remote_hosts , pero no define la propiedad.

Si la propiedad jmeterengine.remote.system.exit se establece en verdadero (el valor predeterminado es falso ), entonces JMeter invocará System.exit(0) después de detener RMI al final de una prueba. Normalmente esto no es necesario.

1.4.6 Anulando Propiedades a Través de la Línea de Comando ¶

Las propiedades del sistema Java y las propiedades de JMeter se pueden anular directamente en la línea de comando (en lugar de modificar jmeter.properties ). Para ello, utilice las siguientes opciones:

-D[nombre_propiedad]=[valor]

define un valor de propiedad del sistema java.

-J[nombre_propiedad]=[valor]

define una propiedad JMeter local.

-G[nombre_propiedad]=[valor]

define una propiedad JMeter que se enviará a todos los servidores remotos.

-G[archivo de propiedad]

define un archivo que contiene las propiedades de JMeter para ser enviado a todos los servidores remotos.

-L[categoría]=[prioridad]

anula una configuración de registro, estableciendo una categoría particular en el nivel de prioridad dado.

El indicador -L también se puede usar sin el nombre de la categoría para establecer el nivel de registro raíz.

Ejemplos :

jmeter -Duser.dir=/home/mstover/jmeter_stuff \
    -Jremote_hosts=127.0.0.1 -Ljmeter.engine=DEBUG

jmeter-LDEBUG

1.4.7 Registro y mensajes de error ¶

Aquí hay un ejemplo de archivo log4j2.xml que define dos agregadores de registro y registradores para cada categoría.

<Estado de configuración="WARN" paquetes="org.apache.jmeter.gui.logging">

  <Agregadores>

    <!-- El agregador del archivo de registro principal a jmeter.log en el directorio desde el que se inició JMeter, de forma predeterminada. -->
    <Nombre del archivo="jmeter-log" fileName="${sys:jmeter.logfile:-jmeter.log}" append="false">
      <diseño de patrón>
        <patrón>%d %p %c{1.}: %m%n</patrón>
      </PatternLayout>
    </Archivo>

    <!-- Agregador de registros para el Visor de registros de GUI. Vea abajo. -->
    <GuiLogEvent name="gui-log-event">
      <diseño de patrón>
        <patrón>%d %p %c{1.}: %m%n</patrón>
      </PatternLayout>
    </GuiLogEvent>

  </Agregadores>

  <Registradores>

    <!-- Registrador raíz -->
    <nivel raíz="información">
      <AppenderRef ref="jmeter-registro" />
      <AppenderRef ref="gui-registro-evento" />
    </raíz>

    <!-- SNIP -->

    <!--
      # Ejemplos de registro de Apache HttpClient
    -->
    <!-- # Habilitar conexión de encabezado + registro de contexto - Lo mejor para la depuración -->
    <!--
    <Registrador nombre="org.apache.http" nivel="depuración" />
    <Registrador nombre="org.apache.http.wire" nivel="error" />
    -->

    <!-- SNIP -->

  </Registradores>

</Configuración>

Por lo tanto, si desea cambiar el nivel de registro de la categoría org.apache.http al nivel de depuración, por ejemplo, simplemente puede agregar (o descomentar) el siguiente elemento de registro en el archivo log4j2.xml antes de iniciar JMeter.

  <Registradores>
    <!-- SNIP -->
    <Registrador nombre="org.apache.http" nivel="depuración" />
    <!-- SNIP -->
  </Registradores>

Para obtener más detalles sobre cómo configurar el archivo log4j2.xml , consulte la página de configuración de Apache Log4j 2 .

El nivel de registro para categorías específicas o el registrador raíz también se puede anular directamente en la línea de comandos (en lugar de modificar log4j2.xml ). Para ello, utilice las siguientes opciones:

-L[categoría]=[prioridad]

Anula una configuración de registro, estableciendo una categoría particular en el nivel de prioridad dado. Desde 3.2, se recomienda utilizar un nombre de categoría completo (p. ej., org.apache.jmeter o com.example.foo ), pero si el nombre de la categoría comienza con jmeter o jorphan , org.apache. se antepondrá internamente a la entrada del nombre de categoría para construir un nombre de categoría completo (es decir, org.apache.jmeter o org.apache.jorphan ) para compatibilidad con versiones anteriores.

Ejemplos :

jmeter -Ljmeter.engine=DEBUG

jmeter -Lorg.apache.jmeter.engine=DEBUG

jmeter -Lcom.ejemplo.foo=DEBUG

jmeter-LDEBUG

Diferencias en el registro: prácticas antiguas frente a nuevas :

Como JMeter utiliza SLF4J como API de registro y Apache Log4j 2 como marco de registro desde 3.2, no todos los niveles de registro utilizados antes de 3.2 pueden coincidir exactamente con uno de los nuevos niveles de registro disponibles proporcionados por SLF4J/Log4j2. Por lo tanto, tenga en cuenta las siguientes diferencias y las nuevas prácticas sugeridas si necesita migrar cualquier configuración de registro y código de registro existentes.

LoggingManager.getLoggerFor (categoría de cadena);
LoggingManager.getLoggerForClass();

LoggerFactory.getLogger(categoría de cadena);
LoggerFactory.getLogger(Foo.clase);

Si JMeter detecta un error durante una prueba, se escribirá un mensaje en el archivo de registro. El nombre del archivo de registro se define en el archivo log4j2.xml (o mediante la opción -j , consulte a continuación). El valor predeterminado es jmeter.log y se encontrará en el directorio desde el que se inició JMeter.

El menú Opciones  →  Visor de registro muestra el archivo de registro en un panel inferior en la ventana principal de JMeter.

En el modo GUI, la cantidad de mensajes de error/fatales registrados en el archivo de registro se muestra en la parte superior derecha.

La opción de línea de comandos -j jmeterlogfile permite procesar después de leer el archivo de propiedades inicial y antes de que se procesen otras propiedades. Por lo tanto, permite anular el valor predeterminado de jmeter.log . Los scripts de jmeter que toman un nombre de plan de prueba como parámetro (p. ej ., jmeter-n.cmd ) se han actualizado para definir el archivo de registro utilizando el nombre del plan de prueba, p. ej., para el plan de prueba Test27.jmx , el archivo de registro se establece en Test27. registro _

Cuando se ejecuta en Windows, el archivo puede aparecer simplemente como jmeter a menos que haya configurado Windows para mostrar las extensiones de archivo. [Lo que deberías hacer de todos modos, para que sea más fácil detectar virus y otras cosas desagradables que fingen ser archivos de texto...]

Además de registrar errores, el archivo jmeter.log registra cierta información sobre la ejecución de la prueba. Por ejemplo:

2017-03-01 12:19:20,314 INFORMACIÓN oajJMeter: Versión 3.2.20170301
2017-03-01 12:19:45,314 INFORMACIÓN oajgaLoad: Cargando archivo: c:\mytestfiles\BSH.jmx
2017-03-01 12:19:52,328 INFORMACIÓN oajeStandardJMeterEngine: ¡Ejecutando la prueba!
2017-03-01 12:19:52,384 INFO oajeStandardJMeterEngine: Iniciando 1 subprocesos para el grupo BSH. Rampa hacia arriba = 1.
2017-03-01 12:19:52,485 INFO oajeStandardJMeterEngine: Continuar con error
2017-03-01 12:19:52,589 INFORMACIÓN oajtJMeterThread: subproceso BSH1-1 iniciado
2017-03-01 12:19:52,590 INFO oajtJMeterThread: el subproceso BSH1-1 está terminado
2017-03-01 12:19:52,691 INFO oajeStandardJMeterEngine: Prueba finalizada

El archivo de registro puede ser útil para determinar la causa de un error, ya que JMeter no interrumpe una prueba para mostrar un diálogo de error.

1.4.8 Lista completa de opciones de línea de comandos ¶

Invocar a JMeter como " jmeter -? " imprimirá una lista de todas las opciones de la línea de comandos. Estos se muestran a continuación.

    --?
        imprimir opciones de línea de comando y salir
    -h, --ayuda
        imprimir información de uso y salir
    -v, --versión
        imprimir la información de la versión y salir
    -p, --propfile <argumento>
        el archivo de propiedades jmeter a usar
    -q, --addprop <argumento>
        archivos adicionales de propiedades de JMeter
    -t, --testfile <argumento>
        el archivo jmeter test(.jmx) para ejecutar
    -l, --logfile <argumento>
        el archivo para registrar muestras
    -i, --jmeterlogconf <argumento>
        archivo de configuración de registro jmeter (log4j2.xml)
    -j, --jmeterlogfile <argumento>
        Archivo de registro de ejecución de jmeter (jmeter.log)
    -n, --nongui
        ejecutar JMeter en modo nongui
    -s, --servidor
        ejecutar el servidor JMeter
    -H, --proxyHost <argumento>
        Configure un servidor proxy para que lo use JMeter
    -P, --proxyPort <argumento>
        Configure el puerto del servidor proxy para que lo use JMeter
    -N, --nonProxyHosts <argumento>
        Establecer una lista de hosts no proxy (p. ej., *.apache.org|localhost)
    -u, --username <argumento>
        Establezca el nombre de usuario para el servidor proxy que utilizará JMeter
    -a, --password <argumento>
        Establezca la contraseña para el servidor proxy que utilizará JMeter
    -J, --jmeterproperty <argumento>=<valor>
        Definir propiedades JMeter adicionales
    -G, --globalproperty <argumento>=<valor>
        Definir propiedades globales (enviadas a servidores)
        por ejemplo -Gport=123
         o -Gglobal.propiedades
    -D, --systemproperty <argumento>=<valor>
        Definir propiedades adicionales del sistema
    -S, --systemPropertyFile <argumento>
        archivos adicionales de propiedades del sistema
    -f, --forceDeleteResultFile
        fuerce la eliminación de los archivos de resultados existentes y la carpeta de informes web, si está presente, antes de comenzar la prueba
    -L, --loglevel <argumento>=<valor>
        [categoría=]nivel, por ejemplo, jorphan=INFO, jmeter.util=DEBUG o com.example.foo=WARN
    -r, --ejecutarremoto
        Iniciar servidores remotos (como se define en remote_hosts)
    -R, --remotestart <argumento>
        Inicie estos servidores remotos (anula hosts_remotos)
    -d, --homedir <argumento>
        el directorio de inicio de jmeter para usar
    -X, --salida remota
        Salga de los servidores remotos al final de la prueba (modo CLI)
    -g, --reportonly <argumento>
        generar solo un panel de informes, a partir de un archivo de resultados de prueba
    -e, --reportatenofloadtests
        generar panel de informes después de la prueba de carga
    -o, --reportoutputfolder <argumento>
        carpeta de salida para el panel de informes

Nota: el nombre del archivo de registro de JMeter tiene el formato de SimpleDateFormat (aplicado a la fecha actual) si contiene comillas simples emparejadas, .eg ' jmeter_'yyyyMMddHHmmss'.log '

Si se usa el nombre especial LAST para las banderas -t , -jo o -l , entonces JMeter lo interpreta como el último plan de prueba que se ejecutó en modo interactivo.

1.4.9 Apagado del modo CLI ¶

Antes de la versión 2.5.1, JMeter invocaba System.exit() cuando se completaba una prueba del modo CLI. Esto causó problemas para las aplicaciones que invocan JMeter directamente, por lo que JMeter ya no invoca System.exit() para completar una prueba normal. [Algunos errores fatales aún pueden invocar System.exit() ] JMeter cerrará todos los subprocesos que no sean daemon que inicie, pero es posible que aún queden algunos subprocesos que no sean daemon; estos evitarán que la JVM salga. Para detectar esta situación, JMeter inicia un nuevo subproceso de daemon justo antes de que finalice. Este subproceso daemon espera un momento; si regresa de la espera, entonces claramente la JVM no ha podido salir y el subproceso imprime un mensaje para decir por qué.

La propiedad jmeter.exit.check.pause se puede usar para anular la pausa predeterminada de 2000 ms (2 segundos). Si se establece en 0 , entonces JMeter no inicia el subproceso del daemon.