[PATCH] allow higer averages then 16448ms

Hi, we use haproxy (1.6.9) to balance very long running POST requests (around 50 seconds) to backend servers. It generally works like a charm, but the average queue time and average total session time statistic values are totally screwed up. The problem is that the average is calculated like

Re: [PATCH] allow higer averages then 16448ms

. Best regards Reinhard On 11/25/2016 08:04 AM, Willy Tarreau wrote: > Hi Reinhard, > > On Thu, Nov 24, 2016 at 10:04:31PM +0100, Reinhard Vicinus wrote: >> Hi, >> >> we use haproxy (1.6.9) to balance very long running POST requests >> (around 50 seconds) to backend

option abortonclose in tcp mode valid?

the issue is something completely differently. Please let me know if further information is needed to investigate this issue. Regards Reinhard Vicinus global cpu-map auto:1/1-4 0-3 nbproc 1 nbthread 4 log /dev/loglocal0 log /dev/loglocal1 notice c

Slow backend request processing?

Hi, I have a problem were I don't know were to look further and I hope I can get some pointers. The problem is that during times with a high request count sometimes answers for requests take a long time. So I identified an request that took a long time and got the log entries from the haproxy and

Re: Dynamic Googlebot identification via lua?

Tim, On 9/12/20 4:25 PM, Tim Düsterhus wrote: > Reinhard, > > Am 12.09.20 um 12:45 schrieb Reinhard Vicinus: >> thanks, for your reply and the information. Sorry for my late reply, but >> I had only today time to test. I did try to get the spoa server working >>

Re: Dynamic Googlebot identification via lua?

Tim, Aleksandar, On 9/8/20 11:18 PM, Aleksandar Lazic wrote: > On 08.09.20 22:54, Tim Düsterhus wrote: >> Reinhard, >> Björn, >> >> Am 08.09.20 um 21:39 schrieb Björn Jacke: the only official supported way to identify a google bot is to run a reverse DNS lookup on the accessing IP

Dynamic Googlebot identification via lua?

to increase performance. So as I am not that experienced in lua programming my question is if this is feasible or if I am missing something? Also, if there are other solutions I am not aware I would be thankful if I got pointers. Thanks in advance Reinhard Vicinus

Re: Is spoa thread safe?

n some curl requests: "curl localhost:10001/" the variable sess.iprep.ip_score is only set on the first and n-th request On 9/22/20 8:10 AM, Илья Шипицин wrote: > Can try to rebuild haproxy with thread sanitizer? > > Or describe repro steps > > On Mon, Sep 21, 2020, 9:49 PM R

Is spoa thread safe?

or is this a bug that will hopefully get fixed in the future? Or am I missing something? Kind regards Reinhard Vicinus

Different behavior of multiple track-sc0 in haproxy 2.2

is behavior a bug or a feature? And if it is a feature, is there some documentation somewhere, because there is no change to the track-sc0 option in the configuration documentation. Kind regards Reinhard Vicinus