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.

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...

 Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se      |     ni...@acc.umu.se
 Memory allocation error: Reboot System!

Reply via email to