On Mon, May 8, 2017 at 4:01 PM, Lukas Tribus <lu...@gmx.net> wrote: > Hello, > > > Am 09.05.2017 um 00:38 schrieb redundantl y: > > I am running haproxy 1.5.18-3 on CentOS 7 and need to use the > > stick-table feature to make sure traffic for a specific user persists > > to a given server. > > > > Things work fine when connections come in slowly, however when there's > > numerous simultaneous connections and a stick-table entry doesn't > > exist yet some requests will be sent to both backend servers until > > they eventually stick to just one. > > > > For example, using Apache Bench to test: > > > > ab -c 10 -n 30 'http://example.com/index.php?email=a...@example.com' > > > > I see this in the haproxy log: > > > > May 8 14:49:10 localhost haproxy[4996]: 1.2.3.4:50812 > > <http://1.2.3.4:50812> [08/May/2017:14:49:10.934] http_front > > backend/server-1 0/0/0/7/7 200 222 - - ---- 9/9/9/4/0 0/0 "GET > > /index.php?email=a...@example.com <mailto:a...@example.com> HTTP/1.0" > > May 8 14:49:10 localhost haproxy[4996]: 1.2.3.4:50811 > > <http://1.2.3.4:50811> [08/May/2017:14:49:10.933] http_front > > backend/server-2 0/0/0/8/8 200 222 - - ---- 8/8/8/4/0 0/0 "GET > > /index.php?email=a...@example.com <mailto:a...@example.com> HTTP/1.0" > > May 8 14:49:10 localhost haproxy[4996]: 1.2.3.4:50816 > > <http://1.2.3.4:50816> [08/May/2017:14:49:10.935] http_front > > backend/server-1 0/0/0/7/7 200 222 - - ---- 7/7/7/1/0 0/0 "GET > > /index.php?email=a...@example.com <mailto:a...@example.com> HTTP/1.0" > > May 8 14:49:10 localhost haproxy[4996]: 1.2.3.4:50819 > > <http://1.2.3.4:50819> [08/May/2017:14:49:10.935] http_front > > backend/server-2 0/0/1/6/7 200 222 - - ---- 6/6/6/1/0 0/0 "GET > > /index.php?email=a...@example.com <mailto:a...@example.com> HTTP/1.0" > > May 8 14:49:10 localhost haproxy[4996]: 1.2.3.4:50814 > > <http://1.2.3.4:50814> [08/May/2017:14:49:10.935] http_front > > backend/server-1 0/0/0/7/7 200 222 - - ---- 5/5/5/1/0 0/0 "GET > > /index.php?email=a...@example.com <mailto:a...@example.com> HTTP/1.0" > > May 8 14:49:10 localhost haproxy[4996]: 1.2.3.4:50810 > > <http://1.2.3.4:50810> [08/May/2017:14:49:10.933] http_front > > backend/server-1 0/0/0/9/9 200 222 - - ---- 4/4/4/0/0 0/0 "GET > > /index.php?email=a...@example.com <mailto:a...@example.com> HTTP/1.0" > > May 8 14:49:10 localhost haproxy[4996]: 1.2.3.4:50813 > > <http://1.2.3.4:50813> [08/May/2017:14:49:10.934] http_front > > backend/server-2 0/0/0/8/8 200 222 - - ---- 3/3/3/0/0 0/0 "GET > > /index.php?email=a...@example.com <mailto:a...@example.com> HTTP/1.0" > > May 8 14:49:10 localhost haproxy[4996]: 1.2.3.4:50815 > > <http://1.2.3.4:50815> [08/May/2017:14:49:10.935] http_front > > backend/server-2 0/0/0/7/7 200 222 - - ---- 2/2/2/0/0 0/0 "GET > > /index.php?email=a...@example.com <mailto:a...@example.com> HTTP/1.0" > > May 8 14:49:10 localhost haproxy[4996]: 1.2.3.4:50817 > > <http://1.2.3.4:50817> [08/May/2017:14:49:10.935] http_front > > backend/server-2 0/0/0/7/8 200 222 - - ---- 1/1/1/0/0 0/0 "GET > > /index.php?email=a...@example.com <mailto:a...@example.com> HTTP/1.0" > > May 8 14:49:10 localhost haproxy[4996]: 1.2.3.4:50818 > > <http://1.2.3.4:50818> [08/May/2017:14:49:10.935] http_front > > backend/server-1 0/0/1/6/8 200 222 - - ---- 0/0/0/0/0 0/0 "GET > > /index.php?email=a...@example.com <mailto:a...@example.com> HTTP/1.0" > > May 8 14:49:10 localhost haproxy[4996]: 1.2.3.4:50820 > > <http://1.2.3.4:50820> [08/May/2017:14:49:10.967] http_front > > backend/server-1 0/0/0/5/5 200 222 - - ---- 3/3/2/2/0 0/0 "GET > > /index.php?email=a...@example.com <mailto:a...@example.com> HTTP/1.0" > > May 8 14:49:10 localhost haproxy[4996]: 1.2.3.4:50821 > > <http://1.2.3.4:50821> [08/May/2017:14:49:10.968] http_front > > backend/server-1 0/0/0/4/4 200 222 - - ---- 2/2/2/2/0 0/0 "GET > > /index.php?email=a...@example.com <mailto:a...@example.com> HTTP/1.0" > > May 8 14:49:10 localhost haproxy[4996]: 1.2.3.4:50823 > > <http://1.2.3.4:50823> [08/May/2017:14:49:10.972] http_front > > backend/server-1 0/0/1/5/6 200 222 - - ---- 7/7/7/7/0 0/0 "GET > > /index.php?email=a...@example.com <mailto:a...@example.com> HTTP/1.0" > > May 8 14:49:10 localhost haproxy[4996]: 1.2.3.4:50822 > > <http://1.2.3.4:50822> [08/May/2017:14:49:10.972] http_front > > backend/server-1 0/0/0/8/8 200 222 - - ---- 6/6/6/6/0 0/0 "GET > > /index.php?email=a...@example.com <mailto:a...@example.com> HTTP/1.0" > > [...] > > > > After this point haproxy correctly sends all traffic to server-1. When > > the stick-table entry expires the problem occurs again. > > > > I have tried persisting off a url parameter and source address, both > > exhibit the same issue. > > > > Is haproxy unable to properly handle numerous simultaneous > > (concurrent) requests like this? Is there something I can do to get > > this to work as desired? > > Those 10 concurrent requests are not elaborated sequentially, haproxy is > a event-loop based application and handles those request in parallel. > Meaning in this case all of those 10 request are load-balanced without > stickiness. > > Use "-c 1" and maybe "-k" to enable keepalive in ab, which will be more > inline with what happens in the real world. > > > Regards, > Lukas > > The way ab is being executed is inline with our real world use. A separately hosted application will generate HTML with several (20-30) elements that will be loaded simultaneously by the end user's browser. There isn't a delay, the elements aren't loaded sequentially.
So is this behaviour we're seeing with haproxy expected? There's no additional options we can try to make it create and use a stick-table entry faster? In the mean time, we've changed the load balancing method from round robin to URI and are seeing the behaviour we desire, it'll just carry the risk of not having an even distribution of load to the backend servers. Thanks.
