asynchronous, bidirectional streaming support for request and response #66
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ixes #933, fixes #1387, #1283, fixes #2083) This replaces buffering entire response in memory which might lead to huge memory footprint and possibly to memory exhaustion. use tempfiles of fixed size so disk space is freed as each file sent update callers of http_chunk_append_mem() and http_chunk_append_buffer() to handle failures when writing to tempfile. x-ref: "memory fragmentation leads to high memory usage after peaks" https://redmine.lighttpd.net/issues/758 "Random crashing on FreeBSD 6.1" https://redmine.lighttpd.net/issues/760 "lighty should buffer responses (after it grows above certain size) on disk" https://redmine.lighttpd.net/issues/933 "Memory usage increases when proxy+ssl+large file" https://redmine.lighttpd.net/issues/1283 "lighttpd+fastcgi memory problem" https://redmine.lighttpd.net/issues/1387 "Excessive Memory usage with streamed files from PHP" https://redmine.lighttpd.net/issues/2083
gstrauss
force-pushed
the
bug-949-streaming-request-response
branch
3 times, most recently
from
c9d4369
to
cf1b311
Compare
This replaces buffering entire response prior to sending data to client x-ref: "fastcgi, cgi, flush, php5 problem." https://redmine.lighttpd.net/issues/949
use SSL_MODE_RELEASE_BUFFERS (OpenSSL >= 1.0.0) to free buffers as they are used, to potentially reduce memory footprint of idle SSL connections x-ref: "memory usage when ssl.engine used and large data uploaded through CGI" https://redmine.lighttpd.net/issues/881 "SSL + file upload = lots of memory" https://redmine.lighttpd.net/issues/1265 "Memory usage increases when proxy+ssl+large file" https://redmine.lighttpd.net/issues/1283
This allows admin to configure if response is collected in entirety prior to sending data to client For compatibility with existing configs, default is existing behavior: buffer entire response prior to sending data to client The following are config options, though not all implemented yet // default: buffer entire request body before connecting to backend server.stream-request-body = 0 // stream request body to backend; buffer to temp files server.stream-request-body = 1 // stream request body to backend; minimal buffering might block upload server.stream-request-body = 2 // default: buffer entire response body before sending to client server.stream-request-body = 0 // stream response body to client; buffer to temp files server.stream-request-body = 1 // stream response body to client; minimal buffering might block backend server.stream-request-body = 2 x-ref: "fastcgi, cgi, flush, php5 problem." https://redmine.lighttpd.net/issues/949 "Reimplement upload (POST) handling to match apache/zeus/thttpd/boa functionality" https://redmine.lighttpd.net/issues/376
Set server.stream-request-body = 1 or server.stream-request-body = 2 to have lighttpd connect to backend (CGI, FastCGI, SCGI, proxy) immediately after parsing request headers, and to stream request body as it arrives. default: buffer entire request body before connecting to backend, in order to avoid tying up (limited) backend resources which are often implemented using libraries which wait for entire request body before proceeding. x-ref: "Reimplement upload (POST) handling to match apache/zeus/thttpd/boa functionality" https://redmine.lighttpd.net/issues/376
move code in dynamic handlers (CGI, FastCGI, SCGI, proxy) from *_handle_fdevent() to *_recv_response() for reuse outside the *_handle_fdevent() routine
…283, #1387) Set server.stream-response-body = 1 or server.stream-response-body = 2 to have lighttpd stream response body to client as it arrives from the backend (CGI, FastCGI, SCGI, proxy). default: buffer entire response body before sending response to client. (This preserves existing behavior for now, but may in the future be changed to stream response to client, which is the behavior more commonly expected.) x-ref: "fastcgi, cgi, flush, php5 problem." https://redmine.lighttpd.net/issues/949 "Random crashing on FreeBSD 6.1" https://redmine.lighttpd.net/issues/760 "Memory usage increases when proxy+ssl+large file" https://redmine.lighttpd.net/issues/1283 "lighttpd+fastcgi memory problem" https://redmine.lighttpd.net/issues/1387
(mod_cgi, mod_fastcgi, mod_scgi, mod_proxy)
consolidate repeated code in dynamic handlers which manipulates con->file_finished. Centralize calls to http_chunk_close(). (mod_cgi, mod_fastcgi, mod_scgi, mod_proxy)
(recent commits streamlined dynamic handler flow control)
defer choosing "Transfer-Encoding: chunked" until response header is about to be written
gstrauss
force-pushed
the
bug-949-streaming-request-response
branch
from
cf1b311
to
5863cb5
Compare
lighttpd-git
pushed a commit
that referenced
this pull request
Jun 20, 2016
asynchronous, bidirectional streaming support for request and response Merge branch 'bug-949-streaming-request-response' into gmaster github: closes #66
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New: asynchronous, bidirectional streaming support for request and response
NOTE: streaming support is experimental (and must be enabled in config)
Interfaces and behavior, including defaults, may change, depending on feedback.
default behavior is the existing behavior: fully buffer request body
before contacting backend, and fully buffer response body before sending
to client
The pull request is not as elegant as I would have liked it to be. There is
way too much pre-existing code duplication (with slight modifications) between
mod_cgi, mod_fastcgi, mod_scgi, mod_proxy. Buffer sizes are not configurable
and use sloppy counters (not exact, but slightly fungible limits are applied).
There is still no separate backend timeout. ...and I am sure there are
additional limitations/missing features not listed here.
That said, the pull request is functional in my very limited testing.
Please be aware that much more testing is needed. Please help.
x-ref:
"Reimplement upload (POST) handling to match apache/zeus/thttpd/boa functionality"
https://redmine.lighttpd.net/issues/376
"memory fragmentation leads to high memory usage after peaks"
https://redmine.lighttpd.net/issues/758
"Random crashing on FreeBSD 6.1"
https://redmine.lighttpd.net/issues/760
"memory usage when ssl.engine used and large data uploaded through CGI"
https://redmine.lighttpd.net/issues/881
"lighty should buffer responses (after it grows above certain size) on disk"
https://redmine.lighttpd.net/issues/933
"fastcgi, cgi, flush, php5 problem."
https://redmine.lighttpd.net/issues/949
"Random crashing on FreeBSD 6.1"
https://redmine.lighttpd.net/issues/760
"SSL + file upload = lots of memory"
https://redmine.lighttpd.net/issues/1265
"Memory usage increases when proxy+ssl+large file"
https://redmine.lighttpd.net/issues/1283
"lighttpd+fastcgi memory problem"
https://redmine.lighttpd.net/issues/1387