[combining two replies]
On 02/23/2017 04:47 PM, Yann Ylavic wrote:
On Thu, Feb 23, 2017 at 7:16 PM, Jacob Champion <champio...@gmail.com> wrote:
Power users can break the system, and this is a power tool, right?
It's not about power users, I don't think we can recommend anyone to
use 4MB buffers even if they (seem to) have RAM for it.
Even if this is the case (and I'm still skeptical), there's a middle
ground between "don't let users configure it at all" and "let users
configure it to dangerous extents".
I'm not talking about hardcoding anything, nor reading or sendind hard
limited sizes on filesystem/sockets.
I'm proposing that the configuration relates to how much we "coalesce"
data on output, and all buffers' reuses (though each of fixed size)
should follow the needs.
I consider the fixed block size to be a major tuning point. That's what
I'm referring to with "hardcoding". Coalescing doesn't help performance
if we're bottlenecking on the overhead of tiny blocks. (Even if
*everything* else can be vectored -- and right now, OpenSSL can't be --
allocation itself would still still be a fixed overhead.)
I've no idea how much it costs to have 8K vs 16K records, though.
Maybe in the mod_ssl case we'd want 16K buffers, still reasonable?
We can't/shouldn't hardcode this especially. People who want maximum
throughput may want nice big records, but IIRC users who want progressive
rendering need smaller records so that they don't have to wait as long for
the first decrypted chunk. It needs to be tunable, possibly per-location.
Well, the limit is 16K at the TLS level.
Maximum limit, yes. We also need to not set a minimum limit, which is,
IIUC, what we're currently doing. mod_ssl calls SSL_write() once for
every chunk read from apr_bucket_read().
On 02/23/2017 04:48 PM, Yann Ylavic wrote:
> On Wed, Feb 22, 2017 at 8:55 PM, Daniel Lescohier wrote:
IOW: read():Three copies: copy from filesystem cache to httpd
read() buffer to encrypted-data buffer to kernel socket buffer.
>
> Not really, "copy from filesystem cache to httpd read() buffer" is
> likely mapping to userspace, so no copy (on read) here.
Oh, cool. Which kernels do this? It seems like the VM tricks would have
to be incredibly intricate for this to work; reads typically don't
happen in page-sized chunks, nor to aligned addresses. Linux in
particular has comments in the source explaining that they *don't* do it
for other syscalls (e.g. vmsplice)... but I don't have much experience
with non-Linux systems.
--Jacob
