On 02/23/2017 08:34 AM, Yann Ylavic wrote: > Actually I'm not very pleased with this solution (or the final one > that would make this size open / configurable). > The issue is potentially the huge (order big-n) allocations which > finally may hurt the system (fragmentation, OOM...).
Power users can break the system, and this is a power tool, right? And we have HugeTLB kernels and filesystems to play with, with 2MB and bigger pages... Making all these assumptions for 90% of users is perfect for the out-of-the-box experience, but hardcoding them so that no one can fix broken assumptions seems Bad.
(And don't get me wrong, I think applying vectored I/O to the brigade would be a great thing to try out and benchmark. I just think it's a long-term and heavily architectural fix, when a short-term change to get rid of some #defined constants could have immediate benefits.)
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.
--Jacob
