2009-02-18 10 views
188

Sono in esecuzione Django, FastCGI e Nginx. Sto creando una sorta di API in cui qualcuno può inviare alcuni dati via XML che elaborerò e quindi restituirò alcuni codici di stato per ogni nodo che è stato inviato.Come evitare un timeout del gateway con FastCGI su Nginx

Il problema è che Nginx genererà un timeout del gateway 504 se impiegherò troppo tempo per elaborare l'XML - penso per più di 60 secondi.

Quindi mi piacerebbe impostare Nginx in modo che se le richieste corrispondenti alla posizione/api non scadono per 120 secondi. Quale impostazione lo realizzerà.

Quello che ho finora è:

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

Edit: Quello che ho non funziona :)

+7

È possibile impostare i valori di timeout su "2m" anziché "120". –

+1

Sembra che i dati non vengano trasmessi in streaming ... ovvero che un server inizi a rispondere in 60 secondi o più sembra inaccettabile. –

risposta

235

timeout proxy vengono bene, per i proxy, non per FastCGI ...

Le direttive che influiscono sui timeout FastCGI sono client_header_timeout, client_body_timeout e send_timeout.

Edit: Considerando ciò che ha trovato sul nginx wiki, il send_timeout directive è responsabile per l'impostazione di timeout generale della risposta (che era un po 'fuorviante). Per FastCGI c'è fastcgi_read_timeout che sta interessando lo fastcgi process response timeout.

HTH.

+44

La risposta è stata il fastcgi_read_timeout - grazie! – sheats

+7

Per chiunque usi uwsgi e che abbia questo errore, uwsgi_read_timeout 600; risolto il mio problema – Homer6

+2

La mia domanda qui sarebbe (come un amministratore di server amatoriale) dove vado a cambiare questo? file httpd.conf? – jeffkee

21

per coloro che utilizzano nginx con unicorno e le rotaie, molto probabilmente il timeout è nel file unicorn.rb

mettere un grande timeout in unicorn.rb

timeout 500 

se si sta ancora affrontando problemi, prova avendo fail_timeout = 0 nel proprio upstream in nginx e vedere se questo risolve il problema. Questo è a scopo di debug e potrebbe essere pericoloso in un ambiente di produzione.

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

Se stai facendo downvoting quella che sembra una risposta legittima, puoi per favore commentare perché. Questa risposta mi sembra soddisfacente. –

+3

Penso che le persone lo abbiano downvoted perché si tratta di Django, tuttavia la tua risposta ha risolto il problema del timeout del gateway con Rails + Unicorn :) – ZiggyTheHamster

1

Se si utilizza unicorno.

Vedere top sul server. Probabilmente Unicorn usa il 100% della CPU al momento. Ci sono diversi motivi per questo problema.

  • Controllare le richieste HTTP, alcune delle quali possono essere molto difficili.

  • Controllare la versione di unicorno. Forse lo hai aggiornato di recente, e qualcosa è stato rotto.

0

In http sezione nginx (/etc/nginx/nginx.conf) aggiungere o modificare:

keepalive_timeout 300s 

In server sezione nginx (/ etc/nginx/sites-available/la tua -config-file.com) aggiungere queste righe:

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; 

In php file nel caso 127.0.0.1:9000 (/etc/php/7.X/fpm/pool.d/www.conf) modificare:

request_terminate_timeout = 300 

Spero di aiutarti.

+0

Avrebbe luogo qualcosa di "cattivo" se cambio il tempo a 10000 secondi? – utdev

+0

Non succede niente di male, ma il tuo servizio aspetta più tempo. Puoi cambiarlo come vuoi. –