1. solicitar configuración de tiempo de espera de solicitud
timeout El tiempo de espera se puede configurar manualmente: cree una nueva solicitud http, busque la configuración "Tiempo de espera" en la configuración "Avanzada" y establezca la conexión y el tiempo de respuesta en 2000 ms.
1. Se agotó el tiempo de espera de la conexión solicitada y no se pudo conectar el servidor.
Fenómeno:
El rendimiento de Jmeter es el siguiente: las primeras solicitudes tienen éxito, pero algunas solicitudes posteriores informarán errores y algunas solicitudes tienen éxito.
Error 1:
Código de respuesta: Código de respuesta no HTTP: java .net.SocketTimeoutException
Mensaje de respuesta: Mensaje de respuesta no HTTP: se agotó el tiempo de conexión
razón:
Por lo general, se debe a que hay demasiados subprocesos, un error de tiempo de espera de conexión y el servidor tiene demasiadas solicitudes y no puede manejarlas.
El tiempo para verificar el tiempo de carga es mayor que el tiempo de espera de conexión establecido por la solicitud, por lo que se genera esta excepción. Puede deberse al hecho de que el servidor tiene muchas solicitudes en proceso y el tiempo de procesamiento es largo, lo que hace que jmeter no pueda conectarse al servidor.
Solución: establezca la conexión de tiempo de espera de solicitud http de jmeter y reinicie el servidor
Error 2:
Se agotó el tiempo de espera de la conexión: connect工具
java.net.ConnectException: Se agotó el tiempo de espera de la conexión: conéctese
en java.net.DualStackPlainSocketImpl.connect0(
razón:
Esto se debe principalmente al agotamiento de los números de puerto. Por lo general, el número de puerto de un servidor es probablemente 65535. Se recomienda utilizar este comando para verificar el estado de uso del puerto de la máquina de prueba de esfuerzo y del servidor respectivamente, netstat -nat| grep -i 8080|wc -l, si este número es alrededor de 60,000, puede ser que el número de puerto esté agotado. Al mismo tiempo, verifique el estado de la mayoría de los puertos, que deberían estar en el estado time_wait.
Solución: si el número de puerto está agotado para una máquina de prueba de presión, agregue más máquinas de prueba de presión y use la prueba de presión distribuida jmeter (jmeter activa keep_alive de forma predeterminada)
现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036
Si cuenta los servidores y los números de puerto están agotados, la razón más probable es que el servidor haya abierto una conexión corta, simplemente cambie la configuración de la conexión corta a una conexión larga.
Si el lado del servidor es una conexión corta, cada vez que jmeter inicia una solicitud, creará un protocolo de enlace TCP de tres vías. Después de que se transmiten los datos, el enlace en realidad no está cerrado. El estado del enlace es time_wait. Cuando llegue la siguiente solicitud , se reabrirá y creará un nuevo puerto TCP protocolo de enlace de tres vías, transmisión de datos....
De esta manera, a medida que aumenta el número de solicitudes, habrá cada vez menos puertos, por lo que los puertos se agotarán rápidamente y la mayoría de los puertos estarán en el estado time_wait. Si el servidor también admite conexiones largas, entonces llegará la siguiente solicitud. , la transmisión continuará en el último canal solicitado y el uso del puerto se reducirá considerablemente, evitando efectivamente el problema del agotamiento del puerto. Para un funcionamiento normal, a cada solicitud se le puede asignar un período de tiempo de espera para evitar errores de tiempo de espera de http.
2. La conexión se realiza correctamente, pero se agota el tiempo de lectura.
Si no puede esperar los datos devueltos por el servidor, generalmente es porque la cantidad de consultas solicitadas esta vez es grande, como verificar los vértices de 5 grados. (el tiempo de espera es menor que el tiempo máximo de espera del servidor) error de tiempo de espera de lectura
jmeter desconecta la solicitud antes de que pueda esperar los datos devueltos por el servidor.
Código de respuesta: Código de respuesta no HTTP: java.net.SocketTimeoutException
Mensaje de respuesta: Mensaje de respuesta no HTTP: Se agotó el tiempo de lectura
Cuando ocurre este error, jmeter ya está conectado al servidor. Verifique que el tiempo de carga no exceda el tiempo de espera de solicitud establecido. La posible causa del error es que el servidor no ha procesado la solicitud del hilo, o la conexión se ha interrumpido. desconectado para garantizar la capacidad del servicio.
Para verificar la conjetura, el número de solicitudes simultáneas se envía al servidor durante más de media hora y, después de un período de tiempo, la solicitud recibe una respuesta 503 que confirma la conjetura.
3. La conexión es exitosa, pero el servidor agota el tiempo de espera al consultar datos.
Esto se debe al mecanismo de tiempo de espera del servidor causado por la solicitud en 2. Si el tiempo de consulta excede los 30 segundos, se informará automáticamente un error. (El tiempo de espera es mayor que el tiempo de espera del servidor). Sobre la base de 2, se ha establecido un tiempo de respuesta grande, pero aún es tiempo de espera. Esto debería significar que el servidor ha agotado el tiempo de espera antes de que pueda esperar a que se devuelvan los datos. por la base de datos .
2. Problemas existentes en la propia prensa
1. En la programación de redes, especialmente cuando hay demasiadas conexiones de red nuevas en un corto período de tiempo, a menudo ocurre
java.net.BindException: dirección ya en uso: excepción JVM_Bind
Java.NET.BindException: dirección ya en uso: conectar
razón:
Hay demasiadas operaciones de socket nuevas en un corto período de tiempo, y la operación socket.close () no puede liberar el puerto vinculado inmediatamente, sino que establece el puerto en el estado time_wait y lo libera después de un período de tiempo (el valor predeterminado es 240 s). ). Puedes ver esto con netstat -na y finalmente los recursos del sistema están agotados ( en Windows , el grupo de puertos efímeros está agotado, este rango está entre 1024-5000).
Solución:
En la máquina que ejecuta el agente jmeter, agregue la entrada del registro
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Puerto de usuario máximo 65334
TcpTimedWaitDelay 30
Configuración de ejecución de la herramienta jmeter:
1. En cmd, use el comando regedit para abrir el registro.
2. Haga clic en HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
3. Haga clic derecho en Parámetros
4. Cree un nuevo valor DWORD y configúrelo (decimal) en 30 segundos. Nombre: TcpTimedWaitDelay, valor: 30. Cree un nuevo valor DWORD, (decimal) el número máximo de conexiones es 65534. Nombre: MaxUserPort, valor: 65534
5. Seleccione decimal como base para aumentar el número de puertos de conexión TCP asignables y reducir el tiempo de supervivencia de las conexiones en el estado TIME_WAIT.
6. Después de modificar la configuración, recuerda reiniciar la máquina para que surta efecto.
jmeter devuelve java.net.SocketException: se restablece la conexión después de enviar la solicitud
Esto indica que hay un problema con el servidor de prueba, puedes ir a la página para verificarlo. Es posible que sea posible configurar los ajustes del cliente, como los ajustes de ejecución de la herramienta anteriores.
java.net.SocketException: socket cerrado
paso 1:
Busque la implementación avanzada en la solicitud http, seleccione httpclient 4 y configure la conexión en 15000-300000 milisegundos.
paso 2:
En el directorio bin del directorio de instalación de jmeter, busque jmeter.properties y ábralo. Abra el comentario en la línea 425 y establezca el valor en 1:
httpclient4.retrycount = 1
httpclient4.idletimeout=<tiempo en 1000 ms>
java.lang.OutOfMemoryError: espacio del montón de Java
razón:
Observe la memoria de la máquina que ejecuta jmeter. El uso de memoria es alto y excede el límite de memoria establecido por jmeter.
solución:
Modifique el archivo de configuración de jmeter y ajuste el rango de memoria disponible del servidor
Modifique el archivo /bin/jmeter.bat: busque estas 2 líneas
establecer HEAP=-Xms256m -Xmx256m
establecer NUEVO=-XX:NewSize=128m -XX:MaxNewSize=128m
Cambiar a:
set HEAP=-Xms1024m –Xmx2048m (el valor máximo no puede exceder la mitad de la memoria del sistema)
set NEW=-XX:NewSize=128m -XX:MaxNewSize=512m network
{ "_t" : "StringResultObject", "status" : 1030, "mensaje": "Se produjo un error en el servidor", "datos": nulo, "isSuccess": falso}
Si encuentra la respuesta devuelta por la solicitud anterior, primero debe ir a los registros del lado del servidor y utilizarlos para localizar el problema.
No se pudo inicializar el motor remoto java.rmi.ConnectException: la conexión se negó al host:
razón:
Durante las pruebas distribuidas, existe un problema con el vínculo entre el servidor y el agente. Después de solucionar problemas de una sola máquina, se descubrió que una máquina agente tenía varias tarjetas de red instaladas. Cuando rmi estaba remoto, estaba buscando la tarjeta de red de la máquina virtual, lo que provocó que el enlace fallara.
solución:
Deshabilite las tarjetas de red de máquinas virtuales no utilizadas y restáurelas después de la prueba
java.lang.OutOfMemoryError: espacio del montón de Java
Razón :
jmeter es una herramienta de desarrollo de Java pura. La memoria es administrada por la máquina virtual Java JVM. Cuando la memoria no se recicla a tiempo y la memoria del montón es insuficiente, se informará un error de desbordamiento de memoria.
Suplemento conceptual:
Pérdida de memoria: la aplicación no libera recursos a tiempo después de usarlos, lo que provoca que se retengan recursos innecesarios en la memoria de la aplicación.
Desbordamiento de memoria: la memoria de la aplicación ya no puede satisfacer el uso normal y la pila ha alcanzado el valor máximo establecido por el sistema, lo que provoca un bloqueo.
Generalmente se debe a una pérdida de memoria que hace que la memoria de la pila aumente continuamente, provocando un desbordamiento de la memoria. Lo mismo ocurre con jmeter: durante la prueba de jmeter, si la memoria se desborda, generalmente aparecerá el mensaje anterior: java.lang.OutOfMemoryError: el espacio del montón de Java significa que la memoria del montón se desborda y no es suficiente.
Solución:
Sabiendo que el motivo del error se debe a un tamaño de memoria del montón insuficiente, es natural pensar en una solución al desbordamiento de la memoria: ajustar el tamaño de la memoria del montón.
Pasos (tomando el sistema Windows como ejemplo, el sistema Linux es similar):
1. Abra el archivo jmeter.bat, busque por la palabra clave "HEAP" y cambie la configuración original a la siguiente: Antes de la modificación:
si no está definido HEAP (
rem Consulte el archivo de inicio de Unix para conocer la justificación de los siguientes parámetros,
rem incluye algunas recomendaciones de ajuste
establecidas HEAP=-Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m
)
)
Después de la modificación:
si no está definido HEAP (
rem Consulte el archivo de inicio de Unix para conocer la justificación de los siguientes parámetros,
rem incluye algunas recomendaciones de ajuste
set HEAP=-Xms512m -Xmx4000m
set NEW=-XX:NewSize=256m -XX:MaxNewSize=512m
)
set HEAP= -Xms512m -Xmx4000m: ajusta el tamaño del
conjunto de memoria del montón NEW=-XX:NewSize=256m -XX:MaxNewSize=512m: ajusta el tamaño de la nueva banda en la memoria del montón
PD:
Este valor no es mayor, mejor. Depende de la máquina utilizada para la prueba de esfuerzo. En términos generales, el valor máximo de la memoria del montón no debe exceder la mitad de la memoria física, de lo contrario, fácilmente hará que jmeter se ejecute lentamente y se congele. O incluso desbordamiento de memoria (debido al propio Java El mecanismo de recolección de basura asigna dinámicamente memoria, que a su vez ocupará mucha memoria al realizar el ajuste), y la memoria asignada por NEW no debe ser demasiado grande.
1. Una vez completada la modificación, guárdela y reinicie JMeter para que surta efecto.
3. Resumen
1. Este método de modificar el tamaño del montón solo es aplicable a algunas situaciones y no es universal. Cuando el número de subprocesos a simular es grande, se deben adoptar pruebas de estrés distribuidas de acuerdo con la situación específica.
2. Cuando ejecute jmeter desde la línea de comando, asegúrese de deshabilitar los oyentes como "Ver árbol de resultados" y "Informe de agregación" porque realmente consume memoria.
3. Las herramientas de monitoreo de disco incluyen iostat y htop.
4. Las herramientas de monitoreo de red incluyen iftop.
5. Para verificar el estado de la conexión de red, use netstat -n | find /I "establecido" /c.
Finalmente, me gustaría agradecer a todos los que leyeron atentamente mi artículo. Mirando el aumento de fans y atención, siempre hay algo de cortesía. Aunque no es algo muy valioso, si puedes usarlo, ¡puedes llevarlo directamente!
Documento de entrevista de prueba de software
Debemos estudiar para encontrar un trabajo bien remunerado. Las siguientes preguntas de la entrevista provienen de los últimos materiales de entrevista de empresas de Internet de primer nivel como Alibaba, Tencent, Byte, etc., y algunos jefes de Byte han dado respuestas autorizadas. Después de terminar esto set Creo que todos pueden encontrar un trabajo satisfactorio según la información de la entrevista.
