Premisa:
Hoy, al hacer una prueba de presión jmeter en una interfaz, encontré el fenómeno:
El número de subprocesos = 100, el número de ciclos = 20, pero cuando la solicitud llega a más de 40 solicitudes, se
informa un error en el resultado de la respuesta de la solicitud subsiguiente - éxito ---
hay un error en el medio del error exitoso, y el resto son La CPU que informó el error solo aumentó a 6-7%
Dividido en dos errores:
Error 1:
java.net.SocketException: socket cerrado
en java.net.SocketInputStream.socketRead0 (Método nativo)
en java.net.SocketInputStream.socketRead (Fuente desconocida)
en java.net.SocketInputStream.read (Fuente desconocida)
en java.net.SocketInputStream .read (Fuente desconocida)
en org.apache.http.impl.io.SessionInputBufferImpl.streamRead (SessionInputBufferImpl.java:137)
en org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer (SessionInputBufferImpl.java:153)
en org. .apache.http.impl.io.SessionInputBufferImpl.readLine (SessionInputBufferImpl.java:280)
en org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead (DefaultHttpResponseParser.java:138)
en org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead (DefaultHttpResponseParser.java:56)
en org.apache.http.impl.io.AbstractMessageParser.parse (AbstractMessageParser.java:259)
en org.apache.http.impl .DefaultBHttpClientConnection.receiveResponseHeader (DefaultBHttpClientConnection.java:163)
en org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader (CPoolProxy.java:157)
en org.apache.http.Rec. )
en org.apache.http.protocol.HttpRequestExecutor.execute (HttpRequestExecutor.java:125)
en org.apache.http.impl.execchain.MainClientExec.execute (MainClientExec.java:272)
en org.apache.http.impl. execchain.ProtocolExec.execute (ProtocolExec.java:186)
en org.apache.http.impl.execchain.RetryExec.execute (RetryExec.java:89)
en org.apache.http.impl.execchain.RedirectExec.execute (RedirectExec.java:110)
en org.apache.http.impl .client.InternalHttpClient.doExecute (InternalHttpClient.java:185)
en org.apache.http.impl.client.CloseableHttpClient.execute (CloseableHttpClient.java:83)
en org.apache.jmeter.protocol.http.sampler.HTPp.sampler.HTp. (HTTPHC4Impl.java:850)
en org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample (HTTPHC4Impl.java:561)
en org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sampler (HTTamplerProxy.sampler) : 67)
en org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample (HTTPSamplerBase.java:1282)
en org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample (HTTPSamplerBase.java:1271)
en org.apache.jmeter.threads.JMeterThread.doSampling (JMeterThread.java:627)
en org.thpareads.jmeter .JMeterThread.executeSamplePackage (JMeterThread.java:551)
en org.apache.jmeter.threads.JMeterThread.processSampler (JMeterThread.java:490)
en org.apache.jmeter.threads.JMeterThread.run (JMeterThread.java:257)
a java.lang.Thread.run (fuente desconocida)
Baidu aprendió que la causa de java.net.SocketException: el error de socket cerrado suele ser que el tiempo de espera de la conexión no está configurado.
Solución:
El problema puede resolverse mediante los siguientes métodos.
Si Usar KeepAlive está marcado en el Básico de la Muestra de solicitud HTTP, se recomienda ir a la pestaña Avanzado:
1. La implementación se selecciona como HttpClient4
2. Connect in Timeouts generalmente establece un valor de 10 a 60 segundos, que indica el tiempo de inactividad de la conexión, para evitar la desconexión causada por el encabezado Keep-Alive que no recibe la respuesta del terminal de prueba de presión.
La unidad de este valor es milisegundos: 15s * 1000 = 15000s
Después de configurar mediante el método anterior, la prueba de presión nuevamente, este error aún ocurrirá
Baidu otra vez
Error 2:
<html>
<head> <title> 502 Bad Gateway </title> </head>
<body bgcolor = "white">
<center> <h1> 502 Bad Gateway </h1> </center>
<hr> <center > nginx / 1.10.3 </center>
</body>
</html>
No hemos verificado:
la solución que Baidu llegó por primera vez: en
general, es causada por la lenta respuesta del proceso fastcgi predeterminado de nginx, pero hay otras situaciones. Aquí resumo algunas soluciones para su referencia.
-
Situación 1: el búfer de respuesta del proceso fastcgi predeterminado de nginx es demasiado pequeño
En este caso, se suspende el proceso fastcgi. Si el procesamiento de suspensión del equipo de servicio fastcgi no es muy bueno, puede provocar un error "504 Gateway Time-out".
-
Solución del caso uno:
El búfer de respuesta de proceso fastcgi predeterminado es 8K, podemos configurarlo un poco más grande, en nginx.conf, agregue: fastcgi_buffers 8 128k
Esto significa configurar el búfer fastcgi en 8 bloques de 128k.
-
Solución del caso uno (mejora):
Después de modificar el método anterior, si todavía hay un problema, podemos continuar modificando el parámetro de tiempo de espera de nginx y aumentar el parámetro un poco, como configurarlo en 60 segundos:
send_timeout 60;
Después del ajuste de estos dos parámetros, el resultado ya no genera el error "504 Gateway Time-out", lo que indica que el efecto es bastante bueno y que el problema está básicamente resuelto.
-
Caso dos: problema de configuración del entorno PHP
Aquí necesitamos modificar la configuración de php-fpm y nginx. En este caso, también aparecerá el mensaje de error "504 Gateway Time-out".
-
Solución para la situación dos (modificación de la configuración de php-fpm):
Cambie max_children de 10 a 30 antes, esta operación es para garantizar que haya suficientes procesos php-cgi que puedan usarse.
Cambie request_terminate_timeout de los 0 segundos anteriores a 60 segundos, de modo que el tiempo de espera del proceso php-cgi para procesar el script se incremente a 60 segundos, lo que puede evitar que el proceso se suspenda para mejorar la eficiencia de la utilización.
-
Solución para la situación dos (configuración nginx modificada):
Para reducir el número de solicitudes fastcgi e intentar mantener los búferes sin cambios, necesitamos cambiar varios elementos de configuración de nginx de la siguiente manera:
Cambió fastcgi_buffers de 4 64k a 2 256k;
Cambie fastcgi_buffer_size de 64k a 128k;
Cambie fastcgi_busy_buffers_size de 128k a 256k;
Cambie fastcgi_temp_file_write_size de 128k a 256k.
-
En el caso dos, la solución se modifica, necesitamos volver a cargar la configuración de php-fpm y nginx, y luego probar. Después de eso, no se encontró el error "504 Gateway Time-out", ¡y el efecto sigue siendo bueno!
https://jingyan.baidu.com/article/6fb756ecbf4774241858fb9a.html