Hi guys, On Mon, Mar 27, 2017 at 02:57:38PM -0700, Grant Zhang wrote: > > sign verify sign/s verify/s > > rsa 2048 bits 0.000745s 0.000034s 1342.9 29050.3 > > Hmm, the numbers are less than what I've seen: (...)
This is an atom C2518 and it seems that --disable-prf has cut the performance in half. We should receive a 8920 soon. > > Stopping the injection, the haproxy process continue to steal cpu doing > > nothing (top shows ~50% of one core, mainly in user): > Hmm, an idle haproxy process with qat enabled consumes about 5% of a core in > my test. 50% is too much:-(. In theory it should not consume anything anymore if it has nothing to do, so maybe the 5% you observed will help understand what is happening. > > Here my haproxy's config: > > global > > tune.ssl.default-dh-param 2048 > > ssl-engine qat > > ssl-async > > > > listen gg > > mode http > Hmm, I have been testing with tcp mode (which is what we use in prod env). > Any chance you have a test with tcp mode and see if you could reproduce the > same issue? I don't think there will be any difference but you're right, it would be useful to know. However what I suspect based on epoll_wait() reporting events that are not dealt with is that the fd owner is NULL (but it should not be without the FD being closed) or is still set but does not point to the proper object after too fast a reuse (eg: async engine vs connection). This would also explain the crash. One test you could both run consists in disabling epoll and trying with poll() by starting haproxy with "-de" (or "noepoll" in the global section). Cheers, Willy
