Hi Cyril, On Sat, Jan 23, 2016 at 11:55:27PM +0100, Cyril Bonté wrote: > From my first tests, I can see a performance drop between commit > 5506e3f8 and e583ea58 (before 1.6-dev1). > > Here is the sample configuration I use : > global > tune.ssl.default-dh-param 2048 > > listen test > mode http > bind :9443 ssl crt localhost.pem > server s localhost:80 > > > At commit 5506e3f8 (BUG/MINOR: stats: correctly set the request/response > analysers) > > $ ab -n1000 -c1 -k https://127.0.0.1:9443/1mb > Time taken for tests: 2.403 seconds > Requests per second: 416.08 [#/sec] (mean) > > The next commit (5be2f352 MAJOR: polling: centralize calls to I/O > callbacks) seems to break keep-alive, I can't test any commit until > e583ea58 where I have this result (still true with current 1.7 head) : > > $ ab -n1000 -c1 -k https://127.0.0.1:9443/1mb > Time taken for tests: 2.933 second > Requests per second: 340.97 [#/sec] (mean)
Interesting, approximately the same drop as observed by Gary. Given that we're dealing with large blocks and that the drop is not observed on smaller objects nor in clear, I suspect we're calling the SSL stack too many times (eg: polling may not be properly disabled when a buffer is full or something like this). I'll profile the calls to try to understand what may be happening. Interestingly, the 40 Gbps test I mentionned was run just before these changes. Kudos for having bisected it around that area! I guess we should be able to reproduce the issue with 1 GB transfers so that we don't care about keep-alive. Cheers, Willy
