httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Champion <champio...@gmail.com>
Subject Re: httpd 2.4.25, mpm_event, ssl: segfaults
Date Mon, 27 Feb 2017 18:16:35 GMT
[combining two replies]

On 02/23/2017 04:47 PM, Yann Ylavic wrote:
> On Thu, Feb 23, 2017 at 7:16 PM, Jacob Champion <champion.p@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

Mime
View raw message