2009-02-18 13 views
188

Używam Django, FastCGI i Nginx. Tworzę api rodzajów, w których ktoś może przesłać pewne dane za pośrednictwem XML, które będę przetwarzać, a następnie zwrócić niektóre kody stanu dla każdego węzła, który został wysłany.Jak zapobiec przekroczeniu limitu czasu bramy za pomocą FastCGI na Nginx

Problem polega na tym, że Nginx wyrzuci limit czasu bramki 504, jeśli zajmie mi to zbyt dużo czasu na przetworzenie XML - myślę, że dłużej niż 60 sekund.

Tak więc chciałbym skonfigurować Nginx, aby wszelkie żądania pasujące do lokalizacji/interfejsu API nie kończyły się na 120 sekund. Jakie ustawienie to osiągnie.

Co mam tak daleko jest:

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

Edycja: Co mam nie działa :)

+7

Możesz ustawić wartości limitu czasu na "2m" zamiast "120". –

+1

Wygląda na to, że dane nie są przesyłane strumieniowo ... tzn. Że serwer, który zacznie odpowiadać w ciągu 60 sekund lub dłużej, wydaje się nie do przyjęcia. –

Odpowiedz

235

timeoutów pełnomocnika są dobrze, proxy, a nie dla FastCGI ...

Dyrektywy wpływające na limity czasu FastCGI to: client_header_timeout, client_body_timeout i send_timeout.

Edit: Biorąc pod uwagę to, co znajduje się na nginx wiki The send_timeout directive jest odpowiedzialny za ustawienie ogólny limit czasu odpowiedzi (który był nieco mylący). Dla FastCGI jest fastcgi_read_timeout, który ma wpływ na fastcgi process response timeout.

HTH.

+44

Odpowiedzią było fastcgi_read_timeout - dzięki! – sheats

+7

Dla każdego używającego uwsgi i posiadającego ten błąd, uwsgi_read_timeout 600; naprawiłem mój problem. – Homer6

+2

Moje pytanie byłoby (jako administrator serwera), gdzie mam go zmienić? plik httpd.conf? – jeffkee

21

dla osób korzystających z nginx jednorożec i szyn, najprawdopodobniej timeout jest w pliku unicorn.rb

położyć duży limit czasu w unicorn.rb

timeout 500 

jeśli nadal napotyka problemy, spróbuj posiadanie fail_timeout = 0 w twoim źródle w nginx i zobacz, czy to rozwiąże twój problem. Ma to na celu debugowanie i może być niebezpieczne w środowisku produkcyjnym.

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

Jeśli ignorujesz coś, co wydaje się być uzasadnioną odpowiedzią, czy możesz skomentować dlaczego. Ta odpowiedź wydaje mi się w porządku. –

+3

Myślę, że ludzie go zaostrzyli, ponieważ chodzi o Django, jednak twoja odpowiedź naprawiła problem przekroczenia limitu czasu bramy z Rails + Unicorn :) – ZiggyTheHamster

1

Jeśli używasz jednorożca.

Spójrz na top na swoim serwerze. Unicorn prawdopodobnie używa teraz 100% CPU. Istnieje kilka przyczyn tego problemu.

  • Powinieneś sprawdzić swoje żądania HTTP, niektóre z nich mogą być bardzo trudne.

  • Sprawdź wersję jednorożca. Być może zaktualizowałeś go niedawno i coś się zepsuło.

0

W http sekcji nginx (/etc/nginx/nginx.conf) dodać lub zmodyfikować:

keepalive_timeout 300s 

W server sekcji nginx (/ etc/nginx/strony-available/Your -config-file.com) dodać te linie:

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; 

W php plik w przypadku 127.0.0.1:9000 (/etc/php/7.X/fpm/pool.d/www.conf) AKTUALIZACJA:

request_terminate_timeout = 300 

Mam nadzieję, że ci pomogę.

+0

Czy coś złego się stanie, jeśli zmienię czas na 10000 sekund? – utdev

+0

Nie dzieje się nic złego, ale twoja usługa czeka więcej czasu. Możesz zmienić wartość, jak chcesz. –