Basic
Basic

Reputation: 26766

How to track down a Python/Django/uwsgi/nginx timeout

I've got the following setup...

When otherhost is busy, some requests are expected to take up to 10 minutes to complete. Unfortunately, after exactly 2 minutes, nginx gives a 502 Bad Gateway.

As far as I can see, the problem has to be one of...

nginx timeout:

I believe this is unlikely as that would be a 504 but I'm using:

proxy_read_timeout 1800;
proxy_connect_timeout 1800;

uwsgi #1 timeout:

I'm launching uwsgi like this (in both cases)

nohup uwsgi --http :8000 --chdir /opt/Path/To/Project --module Project.wsgi
            --virtualenv /opt/pyenv --enable-threads --logto /var/log/LogFile.log -p 1
            --threads 50 -t 1800 2> /dev/null &

Django site 1 calling site 2:

The call is being made like this:

    response = urllib.request.urlopen(Url, urlencode(Data).encode("utf-8"), 
               timeout=1800).read().decode("utf-8")

Site 2 calling othersite:

This is being done by a library which uses the HTTPConnectionPool. I've configured a timeout of 10 minutes. I think this is unlikely as setting it to (say) 2s results in an Http 500 on timeout...

I've scanned my codebase for timeout (and 120, 120000, and even, in desperation 2) but I can't find anywhere the timeout is being set - I assume it's a default from something.

If I skip nginx and do:

curl -m1800 -XGET 'http://localhost:10000/UI/Url'

I get

curl: (52) Empty reply from server

After exactly one minute.

Is there anything obvious that I'm missing? What's a good way to track this one down?

Upvotes: 1

Views: 5164

Answers (2)

user1600649
user1600649

Reputation:

Try increasing uwsgi_read_timeout.

Upvotes: 0

roberto
roberto

Reputation: 12953

You have a pretty "strange" setup:

nginx -> uwsgi http router -> uwsgi

instead of

nginx -> uwsgi

maybe you have some good reason for it, but in such a case you need to set the timeout between uwsgi http router and uwsgi via --http-timeout 1800

If the http router is not you want/need you can just let uwsgi speaks http with the --http-socket option

Upvotes: 2

Related Questions