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.
>>
>> TL;DR:
>> - 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.


Regards,
Yann.

Reply via email to