On Thu, Feb 16, 2017 at 11:48 AM, Niklas Edmundsson <[email protected]> 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.
