We observed that a dynamic server which health check is down for longer
than slowstart delay at startup doesn't trigger the warmup phase, it
receives full traffic immediately. This has been confirmed by checking
haproxy UI, weight is immediately the full one (e.g. 75/75), without any
throttle
When adding a server dynamically, we observe that when a backend has a
dynamic persistence cookie, the new server has no cookie as we receive
the following HTTP header:
set-cookie: test-cookie=; Expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/
Whereas we were expecting to receive something like the
Hi Amaury!
Sorry for the HTML message, I have to use a *** well-known enterprise MUA :(
Le 22/03/2024 09:09, « Amaury Denoyelle » a écrit :
This patch raises several interrogations. First, dynamic servers are
currently intended to not support cookies, hence why the keyword is
disabled for
When adding a server dynamically, we observe that when a backend has a
dynamic persistence cookie, the new server has no cookie as we receive
the following HTTP header:
set-cookie: test-cookie=; Expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/
Whereas we were expecting to receive something like the
It can be sometimes useful to measure total time of a request as seen
from an end user, including TCP/TLS negotiation, server response time
and transfer time. "Tt" currently provides something close to that, but
it also takes client idle time into account, which is problematic for
keep-alive
Hi Willy,
Thanks you very much for your answer. Let's go with Tu, sounds relevant to me.
I've also slightly updated documentation, please tell me if this is not clear
enough.
Cheers,
Damien
Damien Claisse (1):
MINOR: log: Add "Tu" timer
doc/configuration.txt | 11 +++
inc
Hi Willy,
Le 16/04/2020 17:00, « Willy Tarreau » a écrit :
I'm a bit confused by how it can be efficiently used. Because it still
includes the client-side handshake which only happens before the first
request, so if you're interested in removing idle time from keep-alive
.
Damien Claisse (2):
MINOR: log: rename LOG_FMT_TT constant
MINOR: log: Add "TT" timer
doc/configuration.txt | 8
include/types/log.h | 1 +
src/log.c | 16 ++--
3 files changed, 23 insertions(+), 2 deletions(-)
--
2.20.1
Rename it to LOG_FMT_Tt (same case as Tt timer), to reserve
LOG_FMT_TT for another usage.
---
include/types/log.h | 2 +-
src/log.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/types/log.h b/include/types/log.h
index c348caa1e..3720fe73f 100644
---
It can be sometimes useful to measure total time of a request, including
TCP/TLS negotiation, server response time and transfer time. "Tt"
currently provides something close to that, but it also takes client idle time
into account, which is problematic for keep-alive requests as idle time
can be
It can be sometimes interesting to have a timestamp with a
resolution of less than a second.
It is currently painful to obtain this, because concatenation
of date and date_us lead to a shorter timestamp during first
100ms of a second, which is not parseable and needs ugly ACLs
in configuration to
It can be sometimes interesting to have a timestamp with a
resolution of less than a second.
It is currently painful to obtain this, because concatenation
of date and date_us lead to a shorter timestamp during first
100ms of a second, which is not parseable and needs ugly ACLs
in configuration to
It can be sometimes interesting to have a timestamp with a
resolution of less than a second.
It is currently painful to obtain this, because concatenation
of date and date_us lead to a shorter timestamp during first
100ms of a second, which is not parseable and needs ugly ACLs
in configuration to
It can be sometimes interesting to have a timestamp with
a resolution of less than a second. It is currently painful
to obtain this, because concatenation of date and date_us lead
to a shorter timestamp during the first 100ms of a second, which
is not parseable and needs ugly ACLs in configuration
14 matches
Mail list logo
