On Thu, Feb 23, 2017 at 8:50 PM, Jacob Champion <champio...@gmail.com> wrote: > On 02/22/2017 02:16 PM, Niklas Edmundsson wrote: > > I don't think s_server is particularly optimized for performance anyway. > > Oh, and just to complete my local testing table: > > - test server, writing from memory: 1.2 GiB/s > - test server, mmap() from disk: 1.1 GiB/s > - test server, 64K read()s from disk: 1.0 GiB/s > - httpd trunk with `EnableMMAP on` and serving from disk: 850 MiB/s > - httpd trunk with 'EnableMMAP off': 580 MiB/s > - httpd trunk with my no-mmap-64K-block file bucket: 810 MiB/s > > My test server's read() implementation is a really naive "block on read, > then block on write, repeat" loop, so there's probably some improvement to > be had there, but this is enough proof in my mind that there are major gains > to be made regardless.
Does no-mmap-2MB-block beats MMap on? > >> Going off on a tangent here: >> >> For those of you who actually know how the ssl stuff really works, is it >> possible to get multiple threads involved in doing the encryption, or do >> you need the results from the previous block in order to do the next >> one? > > I'm not a cryptographer, but I think how parallelizable it is depends on the > ciphersuite in use. Like you say, some ciphersuites require one block to be > fed into the next as an input; others don't. Yes, and the cost of scheduling threads for non dedicated cypto device is not worth it I think. But mainly there is not only one stream involved in a typical HTTP server, so probably multiple simulteneous connections already saturate the AES-NI...
