On Thu, Feb 16, 2017 at 11:48 AM, Niklas Edmundsson <ni...@acc.umu.se> wrote:
> On Thu, 16 Feb 2017, Yann Ylavic wrote:
>> Here are some SSL/core_write outputs (sizes) for me, with 2.4.x.
>> This is with a GET for a 2MB file, on localhost...
>> Please note that "EnableMMap on" avoids EnableSendfile (i.e.
>> "EnableMMap on" => "EnableSendfile off"), which is relevant only in
>> the http (non-ssl) case anyway.
>> Outputs (and the patch to produce them) attached.
>> - http + EnableMMap => single write
>> - http + !EnableMMap + EnableSendfile => single write
>> - http + !EnableMMap + !EnableSendfile => 125KB writes
>> - https + EnableMMap => 16KB writes
>> - https + !EnableMMap => 8KB writes
> If you try larger filesizes you should start seeing things being broken into
> chunks even for mmap/sendfile. For example we have
> #define AP_MAX_SENDFILE 16777216 /* 2^24 */
> which is unneccessarily low IMHO.
Good point, I can try to make it configurable.
> Think being able to do 100 Gbps single-stream effectively, that's what we
> need to optimize for now in order to have it in distros some years from now.
> And you will waste a lot of CPU doing small writes at those speeds...
> While I applaud the efforts to get https to behave performance-wise I would
> hate for http to be left out of being able to do top-notch on
> latest&greatest networking :-)
> Granted, latest&greatest CPU:s "only" seem to be able to do approx 5 GB/s
> AES128 per core so it will be hard to reach 100 Gbps single-stream https,
> but I really think we should set the goal high while at it...
Agreed, let's look at the whole scope.