sf at sfritsch
Aug 5, 2013, 1:00 AM
Post #3 of 6
(40 views)
Permalink
|
|
Re: r1470679, async write completion, non blocking writes, and mod_ssl
[In reply to]
|
|
On Mon, 5 Aug 2013, Graham Leggett wrote:
> Are you seeing a specific problem?
Well, when I download a large file over a slow link, the request does not
enter write completion state but rather the worker thread is still hogged
for (nearly) the entire download.
> The way openssl's async behaviour works, is that is the middle of a
> read, openssl might need to write, and in the middle of a write, openssl
> might need to read. Openssl tells you this through the codes
> SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE. You receive these codes,
> re-run the select or poll or whatever with the sense that openssl has
> asked for, and you're done. It is that simple.
AFAICT, that part is ok. But it doesn't solve the problem that one thread
is hogged for every ssl connection.
> Sure, httpd might do all sorts of buffering of reads and writes, but at
> the end of the day it won't matter, because openssl will never attempt
> to write-during read or read-during-write without asking you whether it
> is ok first.
>
> I can see a potential problem if the core decided to buffer a write, but
> in theory that could be solved by mod_ssl simply sending a flush bucket
> down the stack whenever the sense changes. I don't see why the core
> needs to care that the data is a file, or encrypted, or whatever, the
> core should just do what the core does.
Let me recap the way async works in mpm event: There is no way to
interrupt and resume the handler, so the handler always must run to
completion. The only way async write completion can work is if the data
produced by the handler is buffered and is later sent bit by bit in an
async way. However, this cannot be done unconditionally or the memory
usage would grow to infinity. Therefore the core output filter has some
heuristics on when to buffer data for async write completion and when to
do blocking writes instead. In general, if there is more than 64k of data
in memory, this is written to the network in a blocking way. Only if the
buckets are backed by files (and therefore do not use significant memory
before being sent to the network), more than 64k of request data is put
into async write completion.
This is where mod_ssl comes in. It will read the file buckets, encrypt
them, and then we have encrypted data in memory that will cause the core
output filters to do blocking writes. The blocking writes happen while the
handler does ap_pass_brigade() and therefore before the worker thread
which executes the handler is freed.
An ideal solution would put the buffering/decision for
blocking/non-blocking into ap_pass_brigade(). This way other filters like
deflate could also be called asynchronously. But I am not too optimistic
that this can be achieved without API changes.
|
