Server stream-response-bodyDetails » History » Revision 6
Revision 5 (gstrauss, 2017-03-13 17:54) → Revision 6/7 (avij, 2017-08-23 11:03)
h1. Server stream-response-bodyDetails
config options to stream response allows admin to configure if response is collected in entirety prior to sending data to client
table{margin-left: 2em}.
|_.option |_. description |
| server.stream-response-body = 0 | default: buffer entire response body before sending to client |
| server.stream-response-body = 1 | stream response body to client; buffer to temp files |
| server.stream-response-body = 2 | stream response body to client; minimal buffering might block backend |
lighttpd is typically faster than the client and typically faster than the backend.
@server.stream-response-body = 1@
Users who stream large responses will most likely want @server.stream-response-body = 1@ so that lighttpd buffers (to tempfiles) the response from the backend as quickly as the backend produces it, even if lighttpd was unable to send the response as quickly to a (far away) client. Buffering the response from the backend allows the backend to finish sending its response quickly, and then to go on serving other requests. This is quite advantageous when the backend is a fat PHP script compared to the slim lighttpd.
@server.stream-response-body = 2@ is more appropriate when the backend is producing what might be an extremely large stream and it is desired that the backend be *blocked* from sending more response data when lighttpd is unable to send response data just as quickly to the client. While this avoids the tempfiles, it also blocks the backend producer from sending more data, which might be desirable for some use cases, though probably not for the most common use cases. This might be appropriate for large generated responses from a backend to lighttpd on a small embedded system which does not have a large amount of disk space for temporary files. Another use-case where this might be useful is if the backend is streaming large files from disk, and for some reason (such as a backend on a remote machine) is not able to send lighttpd an X-Sendfile response header. (e.g. see X-Sendfile doc in [[Docs_ModFastCGI]])
@server.stream-response-body = 0@ just means that lighttpd should buffer the entire response from the backend before starting to send the response to the client. This currently allows mod_deflate (if configured) to compress the response before sending it to the client. In most cases, the response from the backend is small enough, the backend is located on the same machine as the lighttpd server, and the backend produces the response quickly enough that there is not a big perceived difference between @server.stream-response-body = 0@ and @server.stream-response-body = 1@. However, the tunable exists for those who do have use cases which suggest a different tuning from the default.
If you are operating in a memory constrained environment and use HTTPS, you may also need to set @ssl.read-ahead = "disable"@ to prevent lighttpd from buffering incoming data (e.g. POST data, file uploads). See [[Docs_SSL]] for details.