> Resurrecting a thread from 2015. The issue someone raised was that uwsgi > was logging the error message: "uwsgi_response_write_body_do() TIMEOUT > !!!” when the uwsgi backend was streaming back a very large file (> 1GB) > and how to fix it. > > The unsympathetic responses to that user’s query followed the theme “don’t > serve static files with uwsgi”. While that may be good advice, the > problem can arise (and has, for us) for a uwsgi backend that was not > serving static data, but rather large, dynamically-generated data. > > So I’d like to ask the same question as the original poster: how do you > configure uwsgi to not timeout on long response times from a uwsgi > backend? > > Thanks. —Eric > >
Hi, the "do not serve static files with uWSGI (or whatever application server you use)" is generally a super-simplification of a complex "problem". Wasting your precious processes/threads for a task that can be managed asynchronously (serving static files) is obviously bad, but uWSGI gives you lot of alternatives for mitigating the problem (as well as other application servers expecially in the java world). We do not have to forget that lot of users/customers have no full control over the involved technologies (expecially proxies) so it could happen that a user is forced to delegate the serving of static files to its application (the only part of the stack over which he/she has control). Offloading is absolutely the way to go in such scenarios: http://uwsgi-docs.readthedocs.io/en/latest/OffloadSubsystem.html This page could be useful too: http://uwsgi-docs.readthedocs.io/en/latest/StaticFiles.html Regarding your specific problem, you can increase the socket timeout with the socket-timeout = n option (n is in seconds) This is the maximum amount of time a blocking network call can be stuck before returning error (that is what is happening to you) -- Roberto De Ioris http://unbit.com _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
