Hi,
I did some testing/reviewing of the ssl/event backport proposal
* core, mod_ssl: Lift the restriction that prevents mod_ssl taking
full advantage of the event MPM. Enable the ability for a module
to reverse the sense of a poll event from a read to a write or
vice versa.
The general idea of the patch is good. Unfortunately, the current
version doesn't have much effect. The problem is that the core output
filter, which does all the decisions about buffering, flushing,
blocking, and async write completion, comes after the ssl output
filter. Therefore core_output_filter only sees encrypted data and
never sees file buckets. Therefore it will only do async write
completion if the encrypted data left to send for a request is less
than THRESHOLD_MAX_BUFFER (64k).
To be more efficient the order of the filter doing the
buffering/flushing decitions and the ssl output filter would have to
be reversed. I haven't looked how this could be achieved. Maybe
mod_ssl would have to do its encryption in a AP_FTYPE_NETWORK filter
that comes after the core_output_filter().
Does it make sense to backport the current state nonetheless? While it
seems likely to me that the current API would be sufficient even if
this issue is fixed, it may be prudent to wait with a backport until
we know how the issue should be fixed exactly.
As a related issue, I have noticed that even without ssl, async write
completion does not work too well at the moment. The reason seems that
EnableSendfile/EnableMMAP default to off/on respectively, and that the
core_output_buffer does not treat MMAP buckets like it would treat
file buckets. AFAICS, there is no facility in apr to create anonymous
mmaps and we can assume that an apr_mmap_t is always backed by a file.
Is this correct? I think on some OSs, mmaping /dev/null gives an
anonymous mapping. Can we ignore that case for the purpose of deciding
how much memory a bucket needs?
Cheers,
Stefan
