Hi Christopher, On Thu, Mar 15, 2018 at 04:05:04PM +0100, Christopher Faulet wrote: > From 91b1349b6a1a64d43cc41e8546ff1d1ce17a8e14 Mon Sep 17 00:00:00 2001 > From: Christopher Faulet <cfau...@haproxy.com> > Date: Wed, 14 Mar 2018 16:18:06 +0100 > Subject: [PATCH] BUG/MAJOR: threads/queue: Fix thread-safety issues on the > queues management
[...] > However, be careful. This new implementation should be thread-safe > (hopefully...). But it is not optimal and in some situations, it could be > really > slower in multi-threaded mode than in single-threaded one. The problem is > that, > when we try to dequeue pending connections, we process it from the older one > to > the newer one independently to the thread's affinity. So we need to wait the > other threads' wakeup to really process them. If threads are blocked in the > poller, this will add a significant latency. This problem happens when maxconn > values are very low. Regarding this last section, we are a bit worried about the usability of the new `nbthread` feature in 1.8. It raised a few question on our side: - Is it considered as an experimental feature? - Should we expect potential latencies side effects in some situations as described in your commit message? (and so avoid to use it for low latency usage) - I saw some commits for 1.9 release which probably improves the situation about lockess threading http://git.haproxy.org/?p=haproxy.git;a=commit;h=cf975d46bca2515056a4f55e55fedbbc7b4eda59 http://git.haproxy.org/?p=haproxy.git;a=commit;h=4815c8cbfe7817939bcac7adc18fd9f86993e4fc But I guess they will not be backported for 1.8, right? Best, -- William
