Cómo evito un tiempo de espera de puerta de enlace con FastCGI en Nginx

188

Estoy ejecutando Django, FastCGI y Nginx. Estoy creando una API de donde alguien puede enviar datos a través de XML que procesaré y luego devolveré algunos códigos de estado para cada nodo que se envió.Cómo evito un tiempo de espera de puerta de enlace con FastCGI en Nginx

El problema es que Nginx lanzará un tiempo de espera de puerta de enlace 504 si tardo demasiado tiempo en procesar el XML, creo que más de 60 segundos.

Así que me gustaría configurar Nginx para que si las solicitudes que coinciden con la ubicación/api no caduquen durante 120 segundos. Qué configuración logrará eso.

Lo que tengo hasta ahora es:

# Handles all api calls 
    location ^~ /api/ { 
     proxy_read_timeout 120; 
     proxy_connect_timeout 120; 
     fastcgi_pass 127.0.0.1:8080; 
    }

Editar: Lo que tengo no está funcionando :)

Fuente

2009-02-18 sheats

Puede establecer valores de tiempo de espera en "2 m" en lugar de "120". –

Parece malo que los datos no se transmitan ... es decir, que un servidor empiece a responder en 60 segundos o más parece inaceptable. –

235

tiempos de espera de proxy son así, de representación, no para FastCGI ...

Las directivas que afectan los tiempos de espera de FastCGI son client_header_timeout, client_body_timeout y send_timeout.

Editar: Teniendo en cuenta lo que se encuentra en nginx wiki, la send_timeout directive es responsable de establecer el tiempo de espera general de la respuesta (que era poco engañoso). Para FastCGI hay fastcgi_read_timeout que está afectando al fastcgi process response timeout.

HTH.

Fuente

2009-02-18 19:34:13 zgoda

+44

La respuesta fue el fastcgi_read_timeout - ¡gracias! – sheats

Para cualquiera que use uwsgi y tenga este error, uwsgi_read_timeout 600; arregló mi problema – Homer6

Mi pregunta aquí sería (como un administrador de servidor amateur) ¿a dónde voy a cambiar esto? archivo httpd.conf? – jeffkee

para aquellos que utilizan nginx con unicornio y rieles, más probable es que el tiempo de espera es en su archivo unicorn.rb

ejerzan un gran tiempo de espera en unicorn.rb

timeout 500

si todavía está enfrentando problemas, tratar tener fail_timeout = 0 en tu upstream en nginx y ver si esto soluciona tu problema. Esto es para eliminar fallas y puede ser peligroso en un entorno de producción.

upstream foo_server { 
     server 127.0.0.1:3000 fail_timeout=0; 
}

Fuente

2012-12-11 15:48:33 Abdo

Si está bajando la votación lo que parece ser una respuesta legítima, ¿puede comentar por qué? Esta respuesta me parece bien. –

Creo que la gente votó negativamente porque se trata de Django, pero tu respuesta solucionó el problema de tiempo de espera de mi puerta de enlace con Rails + Unicorn :) – ZiggyTheHamster

Si usa unicornio.

Mirar top en su servidor. Es probable que Unicorn use el 100% de la CPU en este momento. Existen varias razones para este problema.

Debe comprobar sus solicitudes HTTP, algunas de ellas pueden ser muy difíciles.
Compruebe la versión de unicornio. Puede ser que lo hayas actualizado recientemente, y algo se rompió.

Fuente

2015-12-09 00:55:39

En http sección nginx (/etc/nginx/nginx.conf) añadir o modificar:

keepalive_timeout 300s

En server sección nginx (/ etc/nginx/sites-available/su -archivo de configuración.com) añadir estas líneas:

client_max_body_size 50M; 
fastcgi_buffers 8 1600k; 
fastcgi_buffer_size 3200k; 
fastcgi_connect_timeout 300s; 
fastcgi_send_timeout 300s; 
fastcgi_read_timeout 300s;

En php archivo en el caso 127.0.0.1:9000 (/etc/php/7.X/fpm/pool.d/www.conf) modificar:

request_terminate_timeout = 300

Espero les ayude.

Fuente

2017-01-30 20:14:03

¿Pasaría algo "malo" si cambio el tiempo a 10000 segundos? – utdev

No pasa nada malo, pero su servicio espera más tiempo. Puede cambiar el valor como lo desee. –

Cómo evito un tiempo de espera de puerta de enlace con FastCGI en Nginx

Respuesta

Cuestiones relacionadas