Hello Roque, On Tue, Feb 06, 2018 at 05:37:32PM +0100, Roque Porchetto wrote: > Hello, > > I'm working on a scalability test project that currently involves to > simulate several user logins on a system whose load balancing relies on > haproxy (latest stable version 1.8.3). > > In a scenario where 20 or more users try to login to the system, around 20% > of them fail. After intense debugging and analysis of tcpdumps, as far as I > see, the issue seems to come from haproxy: some of the http requests are > malformed, due the headers are inserted in a bad way. Specifically, the > header "http-send-name-header". If that keyword is removed from the haproxy > configuration, the error is no longer reproduced. But http-send-name-header > is needed by the system to manage user-backends relations through cookies.
Argh, that's not fun, because it's the worst option ever brought to haproxy, regularly breaking due to insignificant changes :-( > Here an example of a request malformed by haproxy: > [image: Imágenes integradas 2] (note: in the future, please avoid posting images for header captures, it's quite a pain to read, search and comment on). > That request must have been: > > ... > > X-Balancer-Current-Cookie: SERVERID > > X-Balancer-Current-Server: user-0 > > cancel_url=http.......&__ac_password=myPassword > ... > > > But we can see in the malformed request that the X-Balancer-Current-Server > key-value was inserted inside the body changing the value of __ac_password. Now I'm seeing it. So it means that we're having something wrong with the position computation once data start to come in the buffer. Did you notice this problem with 1.7 or not ? The random speed at which data arrive in the buffer explain the fact that you observe neither 0% nor 100% hit. Could you please check if adding "option http-buffer-request" makes it worse or better ? I guess you'll get either 100% failure or 100% success, this will help troubleshooting (and will possibly help you workaround the issue for some time). Thanks! Willy
