
Intenté preguntar en StackOverflow sin éxito, así que espero que esta comunidad pueda ayudarme a localizar este problema. Disponemos de una aplicación web a la que muchas personas de la empresa necesitan acceder. En ocasiones, la aplicación web parece dejar de responder a las solicitudes.
Por ejemplo, si una página de índice de recursos (por ejemplo, la tabla de pedidos) intenta actualizar la lista de recursos durante una interrupción, solicitará los datos a través de una API, pero la solicitud termina fallando silenciosamente después de un tiempo. La aplicación se vuelve inaccesible con solicitudes de larga duración a casi todos los miembros de la empresa al mismo tiempo durante varios minutos seguidos, pero el acceso a la aplicación durante este período de interrupción o lentitud desde otra red (por ejemplo, datos móviles) funciona. Otros sitios web tampoco parecen verse afectados durante este período.
La pestaña de red del navegador muestra que las solicitudes fallan después de 20 a 40 segundos, pero no hay ningún código de estado. El texto de estado cuando se selecciona la solicitud es fallido net::ERR_CONNECTION_TIMED_OUT. Parece que cuando no haces clic en la solicitud mientras se procesa y abres los detalles más tarde, la pestaña de tiempo dirá que se quedó atascada en la fase Detenido. Pero si abre los detalles de la solicitud mientras se procesa, dirá que se quedó atascado en la fase de conexión inicial. Esto hace que la pestaña de tiempo del detalle de la solicitud parezca poco confiable, ya que lo que muestra parece depender de si estaba inspeccionando la solicitud en el momento en que se procesó o no.
Configuración del servidor:
El servidor no parece mostrar una sobrecarga importante durante este tiempo: máximo 30% de uso de CPU/memoria. El servidor se ejecuta en una gota de Digital Ocean y usa nginx para alojar la aplicación Laravel.
Lo que consideré/probé: Las conexiones de la empresa provienen de la misma IP. Pero si bien la aplicación en sí tiene habilitada la limitación, está vinculada al ID del usuario, devuelve un mensaje de error "Demasiados intentos" y el código de estado 429. Si se trata de un caso de limitación, no debería ser a nivel de aplicación porque la limitación se puede reconocer por el mensaje de error y el código de estado.
Intenté inspeccionar las configuraciones de nginx para encontrar alguna limitación habilitada, pero no parece estar habilitada explícitamente a menos que nginx aplique algún tipo de valor predeterminado. Pero incluso si nginx está habilitado, también debería devolver 429/503, según tengo entendido por lo que leí. Pero en nuestro caso parece que no se devuelven errores ni códigos.
Intenté comunicarme con DigitalOcean y el ISP de la compañía y ambos afirman no estar utilizando ningún tipo de mecanismo de aceleración/limitación de velocidad. El administrador de la red de la empresa también dice que no existe tal mecanismo en ejecución.
¿Qué puedo hacer para depurar/investigar de dónde viene el problema? Por lo que tengo entendido, el problema puede ser desde la configuración de nginx hasta la limitación del proveedor de ISP. Estoy pensando que esto es algún tipo de limitación en este momento, pero podría estar perdiendo algo.
Respuesta1
Utilice herramientas de diagnóstico para identificar cuellos de botella o errores en varias partes de su infraestructura (nginx, Digital Ocean, red interna). Registre datos durante la interrupción para analizarlos más tarde.
# nginx logs
tail -f /var/log/nginx/access.log
tail -f /var/log/nginx/error.log
# Network diagnostics (replace x.x.x.x with server IP)
traceroute x.x.x.x
mtr --report --report-cycles=10 x.x.x.x
# Laravel logs
tail -f /path/to/laravel/storage/logs/laravel.log
# Digital Ocean droplet metrics
# Check droplet metrics via Digital Ocean dashboard
Esto le ayudará a determinar si el problema está en la configuración de nginx, en la gota de Digital Ocean, en la red interna o en otro lugar. Los registros y los diagnósticos de red pueden proporcionar pistas.
Responder al comentario
• Para inspeccionar si se aplica alguna regla de limitación o configuración del tráfico mediante el tc
comando, que podría estar influyendo en el flujo del tráfico de la red:
# Display all the traffic control (qdisc) settings on all interfaces:
tc qdisc show dev [interface-name]
# Example for eth0 interface:
tc qdisc show dev eth0
Si se aplican reglas de control de tráfico específicas, se enumerarán aquí. Se pueden analizar más a fondo para determinar si contribuyen a los tiempos de espera informados.