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
--- a/i
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 ve
lternative.
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
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
request
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 ++
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 reques
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
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 p
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 p
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 p
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 fo
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 them.
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 fo
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 appli
Commit 50322df introduced the init-state keyword, but it didn't enable
it for dynamic servers. However, this feature is perfectly desirable
for virtual servers too, where someone would like a server inlived
through "set server be1/srv1 state ready" to be put out of maintenance
in down state until t
Commit ce6a621ae allowed init-state to be used for dynamic servers but I
forgot to update management doc.
---
doc/management.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/doc/management.txt b/doc/management.txt
index 2117a98de..33d6ea06e 100644
--- a/doc/management.txt
+++ b/doc/manageme
16 matches
Mail list logo
