Re: unique-id-header set twice

[Willy Tarreau]

On Fri, Apr 22, 2016 at 04:37:04PM +0200, Erwin Schliske wrote:
> Hello,
> 
> for some of our services requests pass haproxy twice. As we have set the
> global option unique-id-header this header is added twice.
> 
> Is there a way to avoid this? I could set the header with 'http-request
> set-header', but
> ??? this cannot be configured globally.

I don't know what could cause this. Would you happen to have it in a
defaults section maybe, with your traffic passing through a frontend
and a backend ? If that's what causes it, I think we have a mistake
in the implementation and should ensure it's done only once, just like
x-forwarded-for.

Willy

Re: Regarding client side keep-alive

[Willy Tarreau]

On Fri, Apr 22, 2016 at 02:48:43PM +0200, Baptiste wrote:
> > Basically, I want the client<>haProxy side to use keep alive, but
> > haProxy<>server side to close every connection and open a new one for each
> > request.
> >
> > Is it then correct to use http-server-close?
> 
> You are correct.  Set it up in your defaults section or in both the
> frontend and the backend.
> 
> > Also, has anybody had any issues with http-server-close in high traffic
> > environments? Like lingering connections, connections not closed properly
> > etc.
> 
> This feature has been available for many years and it is very stable
> for many years too :)
> You can use without any issue.

And it used to be the only way to have keep-alive in 1.4 and most users
continue to use it even on 1.5 or 1.6 since it preserves server resources.
It's much better than keep-alive for small to moderate loads when the
servers are very close to the LB since you don't care about the time it
takes to set up a TCP connection.

Cheers,
Willy

Re: haproxy and pcre

[Willy Tarreau]

On Thu, Apr 28, 2016 at 02:36:44PM -0400, CJ Ess wrote:
> I'm wanting to make a case for compiling haproxy against a modern version
> of pcre (supporting jit) when we roll out the next release to my day job.
> Anyone have some numbers handy that show the benefit of doing so?

Please check these two commits, the first one links to a benchmark which
led to implement JIT, and the second one reports numbers with and without
pcre_study() :

   7035132 ("MEDIUM: regex: Use PCRE JIT in acl")
   de89871 ("MEDIUM: regex: Use pcre_study always when PCRE is used, regardless 
of JIT")

Willy

Re: Haproxy running on 100% CPU and slow downloads

[Sachin Shetty]

Thanks Lukas and Willy. I am in the process of getting 1.6.4-20160426
deployed in our QA, I will keep you guys posted.


On 4/29/16, 11:09 AM, "Willy Tarreau"  wrote:

>Hi guys,
>
>On Tue, Apr 26, 2016 at 08:46:37AM +0200, Lukas Tribus wrote:
>> Hi Sachin,
>> 
>> 
>> there is another fix Willy recently committed, its ff9c7e24fb [1]
>> and its in the snapshots [2] since 1.6.4-20160426.
>> 
>> This is supposed to fix the issue altogether.
>> 
>> Please let us know if this works for you.
>
>Yes it should fix this. Please note that I've got one report in 1.5 of
>some huge transfers (multi-GB) stalling after this patch, and since I
>can't find any case where it could be wrong nor can I reproduce it, I
>suspect we may have a bug somewhere else (at least in 1.5) that was
>hidden by the bug this series of patches fix. We had no such report on
>1.6 however.
>
>There's another case of high CPU usage which Cyril managed to isolate.
>The issue has been present since 1.4 and is *very* hard to reproduce,
>I even had to tweek some sysctls on my laptop to see it and am careful
>not to reboot it. It is triggered by *some* pipelined requests. We're
>currently working on fixing it, there are several ways to fix it but
>all of them come with their downsides for now (one of them being a
>different code path between 1.7 and 1.6/1.5/1.4 which doesn't appeal
>me much).
>
>This is why I'm still waiting before issuing a new series of versions.
>
>In the mean time, feel free to test latest 1.6 snapshot and report any
>issues you may face. I've really committed into getting these issues
>fixed once for all, it's getting irritating to see such bugs surviving
>but I never give up the fight :-)
>
>Best regards,
>Willy
>

Re: Haproxy running on 100% CPU and slow downloads

[Willy Tarreau]

Hi guys,

On Tue, Apr 26, 2016 at 08:46:37AM +0200, Lukas Tribus wrote:
> Hi Sachin,
> 
> 
> there is another fix Willy recently committed, its ff9c7e24fb [1]
> and its in the snapshots [2] since 1.6.4-20160426.
> 
> This is supposed to fix the issue altogether.
> 
> Please let us know if this works for you.

Yes it should fix this. Please note that I've got one report in 1.5 of
some huge transfers (multi-GB) stalling after this patch, and since I
can't find any case where it could be wrong nor can I reproduce it, I
suspect we may have a bug somewhere else (at least in 1.5) that was
hidden by the bug this series of patches fix. We had no such report on
1.6 however.

There's another case of high CPU usage which Cyril managed to isolate.
The issue has been present since 1.4 and is *very* hard to reproduce,
I even had to tweek some sysctls on my laptop to see it and am careful
not to reboot it. It is triggered by *some* pipelined requests. We're
currently working on fixing it, there are several ways to fix it but
all of them come with their downsides for now (one of them being a
different code path between 1.7 and 1.6/1.5/1.4 which doesn't appeal
me much).

This is why I'm still waiting before issuing a new series of versions.

In the mean time, feel free to test latest 1.6 snapshot and report any
issues you may face. I've really committed into getting these issues
fixed once for all, it's getting irritating to see such bugs surviving
but I never give up the fight :-)

Best regards,
Willy

Re: [PATCH] BUG/MINOR: log: fix a typo that would cause %HP to log

[Willy Tarreau]

On Tue, Apr 26, 2016 at 01:39:02AM +0200, Nenad Merdanovic wrote:
> Typo was introduced in 57bc891 ("BUG/MEDIUM: log: fix risk of
> segfault when logging HTTP fields in TCP mode") which inverted the
> condition in the test and caused  to be logged when using
> %HP.

G... my bad. Thanks for catching this one Nenad.

Willy

Re: Support for Keep-Alive header and timeouts

[Willy Tarreau]

Hi Lukas,

On Mon, Apr 25, 2016 at 07:29:26PM +0200, Lukas Tribus wrote:
> You are saying force closing the session in the middle of a response leading
> to
> a truncate response and forcing the client to do the request all over again
> is
> something you would consider for your production environment?

Absolutely, all of this does not make any sense (at least presented
like this).

> >With that in mind, it's not overly uncommon behaviour. nginx for
> >example has keepalive_timeout to facilitate the behaviour I'm looking
> >for here
> 
> I think your understanding of what nginx does is flawed.
> 
> First of all nginx won't drop an active session (while a response is in
> flight), so
> unless all of those responses are very short-lived and all clients are fast,
> the
> transaction may endure long enough to hit your firewall thresholds.
> 
> The other thing is just because the server transmits a FIN, doesn't mean the
> client can't send another request.
> 
> 
> What I'm saying is, you cannot guarantee on the HTTP level that a session
> will be closed after a certain amount of time.

For sure!

I was told that IIS supports something nice which is the ability to stop
doing keep-alive after a certain amount of requests or a certain duration.
The goal (as I was told) was to ensure that TLS connections would be
renewed from time to time, and maybe to ensure that any thread or process
handling these requests would be renewed after some time, in order to
limit the impact of possible memory leaks in bogus applications.

Also while this can make sense on the application server to force some
process/threads to stop serving new requests after some time, it is
useless on a proxy or load balancer which is isolated from such components.

Regards,
Willy

Re: [PATCH] BUG/MINOR: dumpstats: Fix the "Total bytes saved" counter in, backends stats

[Willy Tarreau]

On Thu, Apr 28, 2016 at 03:57:09PM +0200, Christopher Faulet wrote:
> Hi,
> 
> This is just a typo fix.

good catch, thanks Christopher,
willy

Re: PATCH 1/2: BUG/MEDIUM lua argument boundary fix

[Willy Tarreau]

On Thu, Apr 28, 2016 at 03:35:14PM +0200, Thierry FOURNIER wrote:
> Hi,
> 
> Thanks for the patch.
> Willy, you can apply these two pathes.

Both patches applied, thanks guys.

David, I'll backport them to 1.6 ASAP.

Cheers,
willy

haproxy and pcre

[CJ Ess]

I'm wanting to make a case for compiling haproxy against a modern version
of pcre (supporting jit) when we roll out the next release to my day job.
Anyone have some numbers handy that show the benefit of doing so?

Re: PATCH 1/2: BUG/MEDIUM lua argument boundary fix

[David CARLIER]

Nice, in case I forgot to mention, would be kind to backport the first in
1.6 branch.

Thanks.
Kindest regards.

On 28 April 2016 at 14:35, Thierry FOURNIER  wrote:

> Hi,
>
> Thanks for the patch.
> Willy, you can apply these two pathes.
>
> Thierry
>
> On Wed, 27 Apr 2016 16:27:16 +0100
> David CARLIER  wrote:
>
> > Hi all,
> >
> > This is a first patch for the lua module already overviewed by Thierry
> > Fournier.
> > This one concerns a bug fix which was spotted by calling a convertor
> (made
> > in C) from within Lua module.
> >
> > Hope it finds its way.
> >
> > Kindest regards.
>
>
> --
>
>

[PATCH] BUG/MINOR: dumpstats: Fix the "Total bytes saved" counter in, backends stats

[Christopher Faulet]

Hi,

This is just a typo fix.

-- 
Christopher Faulet
>From bfc2be71794987fcfb0b5806607617431e23a65d Mon Sep 17 00:00:00 2001
From: Christopher Faulet 
Date: Thu, 28 Apr 2016 15:09:31 +0200
Subject: [PATCH] BUG/MINOR: dumpstats: Fix the "Total bytes saved" counter in
 backends stats

Instead of subtracting ST_F_COMP_OUT (Compression out) from ST_F_COMP_IN
(Compressio in) in backends stats, ST_F_COMP_BYP (Compression bypass) was used.
---
 src/dumpstats.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/dumpstats.c b/src/dumpstats.c
index bb62c41..bfd5b5c 100644
--- a/src/dumpstats.c
+++ b/src/dumpstats.c
@@ -3821,7 +3821,7 @@ static int stats_dump_fields_html(struct chunk *out, const struct field *stats,
 			  U2H(stats[ST_F_COMP_OUT].u.u64),
 			  stats[ST_F_COMP_IN].u.u64 ? (int)(stats[ST_F_COMP_OUT].u.u64 * 100 / stats[ST_F_COMP_IN].u.u64) : 0,
 			  U2H(stats[ST_F_COMP_BYP].u.u64),
-			  U2H(stats[ST_F_COMP_IN].u.u64 - stats[ST_F_COMP_BYP].u.u64),
+			  U2H(stats[ST_F_COMP_IN].u.u64 - stats[ST_F_COMP_OUT].u.u64),
 			  stats[ST_F_BOUT].u.u64 ? (int)((stats[ST_F_COMP_IN].u.u64 - stats[ST_F_COMP_OUT].u.u64) * 100 / stats[ST_F_BOUT].u.u64) : 0,
 		  (stats[ST_F_COMP_IN].u.u64 || stats[ST_F_COMP_BYP].u.u64) ? "":"");
 
-- 
2.5.5

Re: PATCH 1/2: BUG/MEDIUM lua argument boundary fix

[Thierry FOURNIER]

Hi,

Thanks for the patch.
Willy, you can apply these two pathes.

Thierry

On Wed, 27 Apr 2016 16:27:16 +0100
David CARLIER  wrote:

> Hi all,
> 
> This is a first patch for the lua module already overviewed by Thierry
> Fournier.
> This one concerns a bug fix which was spotted by calling a convertor (made
> in C) from within Lua module.
> 
> Hope it finds its way.
> 
> Kindest regards.


--