13. Pruebas remotas

13.1 Configuración de SSL ¶

La configuración más simple es usar un par de clave/certificado para todos los servidores y clientes de JMeter que desee conectar. JMeter viene con un script para generar un almacén de claves que contiene una clave (y su certificado correspondiente) llamado rmi . El script se encuentra en el directorio bin y está disponible para sistemas Windows (llamado bin/create-rmi-keystore.bat ) y sistemas similares a Unix (llamado bin/create-rmi-keystore.sh ). Generará un par de claves, que es válido durante siete días, con una frase de contraseña predeterminada de valor ' cambiarlo '. Se recomienda llamarlo desde dentro del directorio bin .

Cuando ejecute el script, le hará algunas preguntas sobre algunos nombres que incluirá en el certificado. Puede escribir lo que quiera, siempre que la herramienta de almacenamiento de claves lo acepte. Ese valor tiene que coincidir con la propiedad server.rmi.ssl.keystore.alias , que por defecto es rmi . A continuación se muestra una sesión de muestra para crear el almacén de claves.

$ cd jmetro/bin
$ ./create-rmi-keystore.sh
¿Cuál es su nombre y apellido?
  [Desconocido]: rmi
Cual es el nombre de tu unidad organizacional?
  [Desconocido]: el nombre de mi unidad
¿Cuál es el nombre de su organización?
  [Desconocido]: el nombre de mi organización
¿Cómo se llama tu Ciudad o Localidad?
  [Desconocido]: Tu ciudad
¿Cuál es el nombre de su estado o provincia?
  [Desconocido]: Tu estado
¿Cuál es el código de país de dos letras para esta unidad?
  [Desconocido]: XY
¿Es correcto CN=rmi, OU=nombre de mi unidad, O=nombre de mi organización, L=su ciudad, ST=su estado, C=XY?
  [no si

Copie el rmi_keystore.jks generado en la carpeta jmeter/bin o haga referencia a él en la propiedad 'server.rmi.ssl.keystore.file'

La configuración predeterminada para RMI debería funcionar con esta configuración. Copie el archivo bin/rmi_keystore.jks en cada servidor y cliente de JMeter que desee utilizar para su configuración de pruebas distribuidas.

13.2 Hacerlo manualmente ¶

En algunos casos, es posible que la secuencia de comandos jmeter-server no funcione para usted (si está utilizando una plataforma de sistema operativo no anticipada por los desarrolladores de JMeter). Aquí se explica cómo iniciar los servidores JMeter (paso 1 anterior) con un proceso más manual:

Paso 1a: Inicie el Registro RMI

Desde JMeter 2.3.1, el servidor JMeter inicia el registro RMI, por lo que esta sección no se aplica en el caso normal. Para volver al comportamiento anterior, defina la propiedad de JMeter server.rmi.create=false en los sistemas host del servidor y siga las instrucciones a continuación.

JMeter utiliza la invocación de método remoto (RMI) como mecanismo de comunicación remota. Por lo tanto, debe ejecutar la aplicación RMI Registry (que se llama " rmiregistry ") que viene con el JDK y se encuentra en el directorio " bin ". Antes de ejecutar rmiregistry , asegúrese de que los siguientes archivos jar estén en su classpath del sistema:

• JMETER_HOME/lib/ext/ApacheJMeter_core.jar
• JMETER_HOME/lib/jorphan.jar
• JMETER_HOME/lib/logkit-2.0.jar

Paso 1b: Inicie el servidor JMeter

Una vez que se esté ejecutando la aplicación RMI Registry, inicie JMeter Server. Utilice la opción " -s " con el script de inicio de jmeter (" jmeter -s ").

Los pasos 2 y 3 siguen siendo los mismos.

13.3 Consejos ¶

JMeter/RMI requiere una conexión del cliente al servidor. Esto utilizará el puerto que eligió, por defecto 1099 .
JMeter/RMI también requiere una conexión inversa para devolver resultados de muestra del servidor al cliente.
Estos utilizarán puertos de numeración alta.
Estos puertos se pueden controlar mediante la propiedad jmeter llamada client.rmi.localport en jmeter.properties .
Si no es cero, se usará como base para los números de puerto locales para el motor del cliente. Por el momento JMeter abrirá hasta tres puertos comenzando con el puerto definido en client.rmi.localport. Si hay cortafuegos u otros filtros de red entre el cliente y el servidor de JMeter, deberá asegurarse de que estén configurados para permitir el paso de las conexiones. Si es necesario, use un software de monitoreo para mostrar qué tráfico se está generando.

Si está ejecutando Suse Linux, estos consejos pueden ayudar. La instalación predeterminada puede habilitar el firewall. En ese caso, las pruebas remotas no funcionarán correctamente. Los siguientes consejos fueron aportados por Sergey Ten.

Si ve conexiones rechazadas, active la depuración pasando las siguientes opciones.

rmiregistry -J-Dsun.rmi.log.debug=true \
     -J-Dsun.rmi.server.exceptionTrace=true \
     -J-Dsun.rmi.loader.logLevel=verbose \
     -J-Dsun.rmi.dgc.logLevel=verbose \
     -J-Dsun.rmi.transport.logLevel=verbose \
     -J-Dsun.rmi.transport.tcp.logLevel=verbose \

Desde JMeter 2.3.1, el servidor inicia el registro RMI; sin embargo, las opciones aún se pueden pasar desde la línea de comandos de JMeter. Por ejemplo: " jmeter -s -Dsun.rmi.loader.logLevel=verbose " (es decir, omita los prefijos -J ). Como alternativa, las propiedades se pueden definir en el archivo system.properties .

La solución al problema es eliminar los loopbacks 127.0.0.1 y 127.0.0.2 de /etc/hosts . Lo que sucede es que jmeter-server no puede conectarse a rmiregistry si el loopback 127.0.0.2 no está disponible. Use la siguiente configuración para solucionar el problema.

Reemplazar

`dirname $0`/jmeter -s "$@"

Con

HOST="-Djava.rmi.server.hostname=[nombre_del_equipo][dominio_del_equipo] \
      -Djava.security.policy=`dirname $0`/[archivo_política]" \
`dirname $0`/jmeter $HOST -s "$@"

También cree un archivo de política y agregue la línea [nombre_computadora][dominio_computadora] a /etc/hosts .

Con el fin de admitir mejor la tunelización SSH de los canales de comunicación RMI utilizados en las pruebas remotas, desde JMeter 2.6:

• se puede configurar una nueva propiedad " client.rmi.localport " para controlar el puerto RMI utilizado por RemoteSampleListenerImpl
• Para admitir la tunelización del tráfico RMI a través de un túnel SSH como punto final remoto usando un puerto en la máquina local, ahora se permite usar la interfaz de bucle invertido si se ha especificado directamente usando el parámetro Java System Property " java.rmi.server.hostname " .

13.4 Usando un puerto diferente ¶

De forma predeterminada, JMeter utiliza el puerto RMI estándar 1099 . Es posible cambiar esto. Para que esto funcione con éxito, todos los siguientes deben estar de acuerdo:

• En el servidor, inicie rmiregistry usando el nuevo número de puerto
• En el servidor, inicie JMeter con la propiedad server_port definida
• En el cliente, actualice la propiedad remote_hosts para incluir la nueva configuración de host remoto: puerto

Desde JMeter 2.1.1, los scripts de jmeter-server brindan soporte para cambiar el puerto. Por ejemplo, suponga que desea utilizar el puerto 1664 (quizás el 1099 ya esté en uso).

C:\JMETER> ESTABLECER PUERTO_SERVIDOR=1664
C:\JMETER> JMETER-SERVER [otras opciones]

$ SERVER_PORT=1664 jmeter-server [otras opciones]

En ambos casos, el script inicia rmiregistry en el puerto especificado y luego inicia JMeter en modo servidor, habiendo definido la propiedad " server_port ".

El puerto elegido se registrará en el archivo jmeter.log del servidor ( rmiregistry no crea un archivo de registro).

13.5 Usando un remitente de muestra diferente ¶

Los oyentes en el plan de prueba envían sus resultados al cliente JMeter, que escribe los resultados en los archivos especificados. De forma predeterminada, las muestras se envían de vuelta sincrónicamente a medida que se generan. Esto puede afectar el rendimiento máximo de la prueba del servidor; el resultado de la muestra debe devolverse antes de que el hilo pueda continuar. Hay algunas propiedades de JMeter que se pueden configurar para modificar este comportamiento.

modo

modo de envío de muestra: el valor predeterminado es StrippedBatch desde 2.9. Esto debe configurarse en el nodo del cliente.

Estándar

enviar muestras sincrónicamente tan pronto como se generen

Mantener

mantenga las muestras en una matriz hasta el final de una ejecución. Esto puede usar mucha memoria en el servidor y no se recomienda.

Tienda de discos

almacenar muestras en un archivo de disco (en java.io.temp ) hasta el final de una ejecución. El archivo de datos serializados se elimina al salir de JVM.

StrippedDiskStore

elimine los datos de respuesta de las muestras exitosas y use el remitente de DiskStore para enviarlos.

Lote

enviar muestras guardadas cuando el conteo ( num_sample_threshold ) o el tiempo ( time_threshold ) exceda un umbral, momento en el cual las muestras se envían sincrónicamente. Los umbrales se pueden configurar en el servidor utilizando las siguientes propiedades:

num_sample_threshold

número de muestras a acumular, por defecto 100

time_threshold

umbral de tiempo, predeterminado 60000 ms = 60 segundos

Consulte también el modo Asíncrono, que se describe a continuación.

Estadístico

enviar una muestra de resumen cuando el conteo o el tiempo exceda un umbral. Las muestras se resumen por nombre de grupo de subprocesos y etiqueta de muestra. Se acumulan los siguientes campos:

• tiempo transcurrido
• latencia
• bytes
• recuento de muestras
• conteo de errores

Se pierden otros campos que varían entre muestras.

despojado

eliminar los datos de respuesta de las muestras exitosas

Lote despojado

elimine los datos de respuesta de las muestras exitosas y use el remitente por lotes para enviarlos.

asíncrono

las muestras se almacenan temporalmente en una cola local. Un subproceso de trabajo separado envía las muestras. Esto permite que el subproceso de prueba continúe sin esperar a que se envíe el resultado al cliente. Sin embargo, si las muestras se crean más rápido de lo que pueden enviarse, la cola eventualmente se llenará y el subproceso de la muestra se bloqueará hasta que algunas muestras puedan drenarse de la cola. Este modo es útil para suavizar los picos en la generación de muestras. El tamaño de la cola se puede ajustar configurando la propiedad de JMeter asynch.batch.queue.size ( 100 por defecto ) en el nodo del servidor.

despojadoAsynch

elimine los datos de respuesta de las muestras exitosas y use el remitente asíncrono para enviarlos.

Implementación personalizada

establezca el parámetro de modo en su nombre de clase de remitente de muestra personalizado. Este debe implementar la interfaz SampleSender y tener un constructor que tome un único parámetro de tipo RemoteSampleListener .

Las siguientes propiedades se aplican a los modos Batch y Statistical :

num_sample_threshold

número de muestras en un lote (predeterminado 100 )

time_threshold

número de milisegundos a esperar (predeterminado 60 segundos)

13.6 Tratando con nodos que fallaron al iniciarse ¶

Para las pruebas a gran escala, existe la posibilidad de que una parte de los servidores remotos no esté disponible o esté inactivo. Por ejemplo, cuando usa un script de automatización para asignar muchas máquinas en la nube y las usa como generadores, es posible que algunas de las máquinas solicitadas no se inicien debido a problemas de la nube. Desde JMeter 2.13 hay nuevas propiedades para controlar este comportamiento.

Primero, lo que podría querer es volver a intentar los intentos de inicialización con la esperanza de que los nodos fallidos retrasen un poco su arranque. Para habilitar los reintentos, debe establecer la propiedad client.tries en el número total de intentos de conexión. Por defecto solo hace un intento. Para controlar el retraso de los reintentos, establezca la propiedad client.retries_delay en una cantidad de milisegundos para dormir entre intentos.

Finalmente, es posible que aún desee ejecutar la prueba con aquellos generadores que lograron la inicialización y omitieron los nodos fallidos. Para habilitar eso, establezca la propiedad client.continue_on_fail=true .

13.7 Usando un administrador de seguridad ¶

Al ejecutar JMeter en un entorno distribuido, debe tener en cuenta que JMeter es básicamente un agente de ejecución remota tanto en el lado del servidor como en el del cliente. Esto podría ser utilizado por una parte malintencionada para obtener más acceso, una vez que haya comprometido uno de los clientes o servidores de JMeter. Para mitigar esto, Java tiene el concepto de un administrador de seguridad al que la JVM le pregunta antes de que se ejecuten posibles acciones peligrosas. Esas acciones podrían ser resolver nombres de host, crear o leer archivos o ejecutar comandos en el sistema operativo.

El administrador de seguridad se puede habilitar configurando las propiedades del sistema Java java.security.manager y java.security.policy . Asegúrese de echar un vistazo al Paseo rápido por el control de aplicaciones .

Con el nuevo mecanismo de setenv.sh (o setenv.bat en Windows), puede habilitar el administrador de seguridad agregando el siguiente fragmento de código a ${JMETER_HOME}/bin/setenv.sh :

JVM_ARGS="\
   -Djava.seguridad.gestor \
   -Djava.security.policy=${JMETER_HOME}/bin/java.policy \
   -Djmeter.home=${JMETER_HOME} \
"

La JVM ahora agregará las políticas definidas en el archivo ${JMETER_HOME}/bin/java.policy a las políticas posiblemente definidas globalmente. Si desea que su definición sea la única fuente de políticas, use dos signos iguales en lugar de uno al establecer la propiedad java.security.policy .

Las políticas dependerán de su caso de uso y puede llevar un tiempo encontrar las acciones restringidas y permitidas correctas. Java puede ayudarlo a encontrar las políticas necesarias con la propiedad java.security.debug . Configúrelo para acceder y registrará todos los permisos que se le soliciten. Simplemente agregue la siguiente línea a su setenv.sh :

JVM_ARGS="${JVM_ARGS} -Djava.security.debug=acceso"

Puede parecer un poco extraño que definamos una propiedad del sistema Java jmeter.home con el valor de ${JMETER_HOME} . Esta variable se usará en el ejemplo java.policy para limitar el acceso al sistema de archivos y permitirle solo leer la configuración y las bibliotecas de JMeters y restringir el acceso de escritura solo a ubicaciones específicas.

El siguiente archivo de definición de políticas se ha utilizado para una prueba remota simple. Probablemente tendrá que modificar las políticas cuando ejecute escenarios más complejos. Los planes de prueba se colocan en algún lugar dentro del directorio de inicio de los usuarios en un directorio llamado jmeter-testplans . El ejemplo de java.policy se ve así:

conceder codeBase "archivo:${jmeter.home}/bin/*" {
  permiso java.security.AllPermission;
};

conceder codeBase "archivo:${jmeter.home}/lib/jorphan.jar" {
  permiso java.security.AllPermission;
};

conceder codeBase "archivo:${jmeter.home}/lib/log4j-api-2.11.1.jar" {
  permiso java.security.AllPermission;
};

conceder codeBase "archivo:${jmeter.home}/lib/log4j-slf4j-impl-2.11.1.jar" {
  permiso java.security.AllPermission;
};

conceder codeBase "archivo:${jmeter.home}/lib/slf4j-api-1.7.25.jar" {
  permiso java.security.AllPermission;
};

conceder codeBase "archivo:${jmeter.home}/lib/log4j-core-2.11.1.jar" {
  permiso java.security.AllPermission;
};

conceder codeBase "archivo:${jmeter.home}/lib/ext/*" {
  permiso java.security.AllPermission;
};

conceder codeBase "archivo:${jmeter.home}/lib/httpclient-4.5.6.jar" {
  permiso java.net.SocketPermission "*", "conectar, resolver";
};

conceder codeBase "archivo:${jmeter.home}/lib/darcula.jar" {
  permiso java.lang.RuntimePermission "modifyThreadGroup";
};

conceder codeBase "archivo:${jmeter.home}/lib/xercesImpl-2.12.0.jar" {
  permiso java.io.FilePermission "${java.home}/lib/xerces.properties", "leer";
};

conceder codeBase "archivo:${jmeter.home}/lib/groovy-all-2.4.15.jar" {
  permiso groovy.security.GroovyCodeSourcePermission "/groovy/script";
  permiso java.lang.RuntimePermission "accessClassInPackage.sun.reflect";
  permiso java.lang.RuntimePermission "getProtectionDomain";
};

otorgar {
  permiso java.io.FilePermission "${jmeter.home}/backups", "leer, escribir";
  permiso java.io.FilePermission "${jmeter.home}/backups/*", "leer, escribir, borrar";
  permiso java.io.FilePermission "${jmeter.home}/bin/upgrade.properties", "leer";
  permiso java.io.FilePermission "${jmeter.home}/lib/ext/-", "leer";
  permiso java.io.FilePermission "${jmeter.home}/lib/ext", "leer";
  permiso java.io.FilePermission "${jmeter.home}/lib/-", "leer";
  permiso java.io.FilePermission "${user.home}/jmeter-testplans/-", "leer, escribir";
  permiso java.io.SerializablePermission "enableSubclassImplementation";
  permiso java.lang.reflect.ReflectPermission "suppressAccessChecks";
  permiso java.lang.RuntimePermission "accessClassInPackage.jdk.internal.dynalink.support";
  permiso java.lang.RuntimePermission "accessClassInPackage.sun.awt";
  permiso java.lang.RuntimePermission "accessClassInPackage.sun.misc";
  permiso java.lang.RuntimePermission "accessClassInPackage.sun.swing";
  permiso java.lang.RuntimePermission "accessDeclaredMembers";
  permiso java.lang.RuntimePermission "createClassLoader";
  permiso java.lang.RuntimePermission "createSecurityManager";
  permiso java.lang.RuntimePermission "getClassLoader";
  permiso java.lang.RuntimePermission "getenv.*";
  permiso java.lang.RuntimePermission "nashorn.createGlobal";
  permiso java.util.PropertyPermission "*", "leer";
};