What's the difference between uWSGI's socket-timeout/http-timeout/harakiri?

Question

I wrote a simple WSGI application (using Flask) served by uWSGI (i.e. no other HTTP server but uWSGI) which only supports a single PUT route using which clients can upload a file (potentially ~400MB in size), have it processed on the server and then sent back.

In the uWSGI logs, I noticed two kinds of timeout errors after some time. Usually it's a timeout when sending the response:

Feb 02 20:46:30 myserv uwsgi[18948]: uwsgi_response_sendfile_do() TIMEOUT !!!
Feb 02 20:46:30 myserv uwsgi[18948]: OSError: write error
Feb 02 20:46:30 myserv uwsgi[18948]: [pid: 18954|app: 0|req: 1795/3935] aa.bb.cc.dd () {32 vars in 455 bytes} [Fri Feb  2 20:46:06 2018] PUT /sample.exe => generated 0 bytes in 24314 msecs via sendfile() (HTTP/1.1 200) 6 headers in 258 bytes (3353 switches on core 0)

Sometimes though, it's also a timeout when receiving a PUT request:

Feb 03 20:18:32 signserv uwsgi[18948]: [pid: 18953|app: 0|req: 2975/5670] aa.bb.cc.dd () {32 vars in 455 bytes} [Sat Feb  3 20:18:02 2018] PUT /samplefile.exe => generated 0 bytes in 29499 msecs via sendfile() (HTTP/1.1 200) 6 headers in 258 bytes (2930 switches on core 0)
Feb 03 20:20:30 signserv uwsgi[18948]: [uwsgi-body-read] Timeout reading 16384 bytes. Content-Length: 354414781 consumed: 0 left: 354414781

Some debugging suggests that this typically happens with clients which are very slow (i.e. which have a high load).

I'd like to alleviate this by increasing some timeouts, but uWSGI appears to support a plethora of timeouts and it's not clear to me which of them are relevant here. I identified three timeouts which sound like I may want to increase them, but I have trouble finding documentation on how they differ:

• socket-timeout
• http-timeout
• harakiri

Can anyone shed some light on what these timeouts affect, what their default values are and which (if any) of them should be adjusted to avoid above-mentioned issues?

Gearldinegearshift

related: #24128101 – Ley

For what it's worth, setting both socket-timeout as well as http-timeout to 60 made the timeout errors go away. I don't know whether either of them would have been sufficient, but it works now - so I'm a happy camper. Would still be great to have some informative answers though, so I'll leave this question open. – Gearldinegearshift

Answer 1

In simple terms, the harakiri is uWSGI timeout and the http-timeout or the socket-timeout is a balancer/proxy-server timeout.

When these parameters differ, there can be confusion in logs.

Gargantua

This is true. For the difference between socket and http timeout, uwsgi supports running its own http server and if you run it that way, you usually will not run it behind a big webserver like e.g. nginx, apache. For that, you want to configure with http timeout. But if you do employ a reverse proxy, you will want to run it in socket mode. And in that case, you configure with socket timeout. This is explained better here, bullet point 2: uwsgi-docs.readthedocs.io/en/latest/ThingsToKnow.html – Ilysa