Generic backend in HAProxy config with server options as placeholders
Hello, We have a requirement wherein a single generic backend with server options configured as placeholders, which will resolve on the fly or at runtime. Currently, we have to define multiple backends (has to be hardcoded) and select them using the *use_backend* keyword. Kindly help us with this generic backend implementation in HAProxy and let us know if its possible OR any alternative way that this can be achieved. Thank you in advance, Vijay B
[PATCH] CLEANUP: fix typos in reg-tests
Hi,
This patch fixes typos in comments and error messages of reg-tests.
Note that this
has not been qualified as minor as it is used for testing purposes, not
end-users.
Let me know if I need to re-qualify the patch as MINOR (and split it
as one part is comment, one part is info messages).
The patch is attached, but if you want to view the diff online, you
can check:
https://github.com/haproxy/haproxy/compare/master...aerostitch:cleanup_regtests_typos
Thanks for your help,
Joseph
From f202d9aac1327d13a43209fc4bc0a634d6784cdf Mon Sep 17 00:00:00 2001
From: Joseph Herlant
Date: Tue, 13 Nov 2018 20:15:49 -0800
Subject: [PATCH] CLEANUP: fix typos in reg-tests
Fix typos in comments and error messages of reg-tests. Note that this
has not been qualified as minor as it is used for testing purposes, not
end-users.
---
reg-tests/log/b0.vtc | 2 +-
reg-tests/lua/b2.lua | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/reg-tests/log/b0.vtc b/reg-tests/log/b0.vtc
index b28ac94d..99a81cd9 100644
--- a/reg-tests/log/b0.vtc
+++ b/reg-tests/log/b0.vtc
@@ -8,7 +8,7 @@
# requiring LW_BYTES is set), the log is emitted after the connection is
# closed, so the address and ports cannot be retrieved anymore.
#
-# It could be argued that we'd make a special case of these to immediatly
+# It could be argued that we'd make a special case of these to immediately
# retrieve the source and destination addresses from the connection, but it
# seems cleaner to simply pin the front connection, marking it "tracked" by
# adding the LW_XPRT flag to mention that we'll need some of these elements
diff --git a/reg-tests/lua/b2.lua b/reg-tests/lua/b2.lua
index 41e5eeeb..dd5623c1 100644
--- a/reg-tests/lua/b2.lua
+++ b/reg-tests/lua/b2.lua
@@ -106,7 +106,7 @@ core.Info("4")
repeat
local d = socket:receive(res.contentlength)
if d == nil then
---core.Info("luacurl, ERROR?: recieved NIL, expecting "..res.contentlength.." bytes only got "..string.len(res.body).." sofar")
+--core.Info("luacurl, ERROR?: received NIL, expecting "..res.contentlength.." bytes only got "..string.len(res.body).." sofar")
return
else
res.body = res.body..d
@@ -116,7 +116,7 @@ core.Info("4")
break
end
end
--- core.Info("processhttpresponse, Loopy, get more body data! to recieve complete contentlenght")
+-- core.Info("processhttpresponse, Loopy, get more body data! to receive complete contentlenght")
until false
end
if res.headers["Transfer-Encoding"] ~= nil and res.headers["Transfer-Encoding"] == "chunked" then
--
2.19.1
[PATCH] CLEANUP: fix a misspell in tests/filltab25.c
Hi, This is the only typo detected in the tests, so leaving it for a patch of its own. The patch is attached, but if you want to view the diff online, you can check: https://github.com/haproxy/haproxy/compare/master...aerostitch:cleanup_tests_typo Thanks for your help, Joseph From 2037836776fba560c14d5b8e91085752f875b38f Mon Sep 17 00:00:00 2001 From: Joseph Herlant Date: Tue, 13 Nov 2018 20:07:48 -0800 Subject: [PATCH] CLEANUP: fix a misspell in tests/filltab25.c The commit fixes a misspell in a comment of tests/filltab25.c. --- tests/filltab25.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/filltab25.c b/tests/filltab25.c index c57f4207..3bedf25c 100644 --- a/tests/filltab25.c +++ b/tests/filltab25.c @@ -2,7 +2,7 @@ * experimental weighted round robin scheduler - (c) 2007 willy tarreau. * * This filling algorithm is excellent at spreading the servers, as it also - * takes care of keeping the most uniform distance between occurences of each + * takes care of keeping the most uniform distance between occurrences of each * server, by maximizing this distance. It reduces the number of variables * and expensive operations. */ -- 2.19.1
[PATCH] MINOR: fix typos in the examples files
Hi, This patch deals with typos in the example files. To be more specific the error 500 example page and the transparent_proxy.cfg page. For the later, it is all in the comments but still user-visible as those are examples. I wasn't sure if you consider the examples files as documentation or user-visible code, so I used the MINOR severity for the patch. The patch is attached, but if you want to view the diff online, you can check: https://github.com/haproxy/haproxy/compare/master...aerostitch:minor_examples_typo Thanks for your help, Joseph From 7bda552f46cd5d22f8536fa01259a3c18515b1d9 Mon Sep 17 00:00:00 2001 From: Joseph Herlant Date: Tue, 13 Nov 2018 20:01:24 -0800 Subject: [PATCH] MINOR: fix typos in the examples files To be more specific the error 500 example page and the transparent_proxy.cfg page. For the later, it is all in the comments but still user-visible as those are examples. --- examples/errorfiles/500.http | 2 +- examples/transparent_proxy.cfg | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/examples/errorfiles/500.http b/examples/errorfiles/500.http index ebf7d47f..9c3be965 100644 --- a/examples/errorfiles/500.http +++ b/examples/errorfiles/500.http @@ -4,6 +4,6 @@ Connection: close Content-Type: text/html 500 Internal Server Error -An internal server error occured. +An internal server error occurred. diff --git a/examples/transparent_proxy.cfg b/examples/transparent_proxy.cfg index 0ecb20d4..b514ae3b 100644 --- a/examples/transparent_proxy.cfg +++ b/examples/transparent_proxy.cfg @@ -39,11 +39,11 @@ backend TransparentBack_http # /sbin/sysctl net.link.ether.ipfw=1 # ipfw add 10 fwd localhost tcp from 192.168.0.40 80 to any in recv em0 # -# the above does the folowing: +# the above does the following: # - load the ipfw kernal module # - set pf as the outer firewall to keep control of routing packets for example to route them to a non-default gateway # - enable ipfw -# - set a rule to catches reply traffic on em0 comming from the webserver +# - set a rule to catches reply traffic on em0 coming from the webserver # # --- Step 2 --- # To also make the client connection transparent its possible to redirect incomming requests to HAProxy with a pf rule: -- 2.19.1
[PATCH] CLEANUP: fix typos in comments in ebtree
Hi,
This patch is mainly about misspells of the word "occurrence" in the
code of ebtree. The misspells are only located in code comments.
The patch is attached, but if you want to view the diff online, you
can check: https://github.com/haproxy/haproxy/compare/master...aerostitch:ebtree
Thanks for your help,
Joseph
From bca687d8d0d8143ddf5a1669244f7d4e1554bf8b Mon Sep 17 00:00:00 2001
From: Joseph Herlant
Date: Tue, 13 Nov 2018 19:55:57 -0800
Subject: [PATCH] CLEANUP: fix typos in comments in ebtree
This is mainly about misspells of the word "occurrence". The misspells
are only located in code comments.
---
ebtree/eb32tree.h | 4 ++--
ebtree/eb64tree.h | 4 ++--
ebtree/ebimtree.c | 2 +-
ebtree/ebimtree.h | 4 ++--
ebtree/ebistree.c | 2 +-
ebtree/ebistree.h | 4 ++--
ebtree/ebmbtree.c | 6 +++---
ebtree/ebmbtree.h | 8
ebtree/ebsttree.c | 2 +-
ebtree/ebsttree.h | 4 ++--
10 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/ebtree/eb32tree.h b/ebtree/eb32tree.h
index f33eb865..08ff9006 100644
--- a/ebtree/eb32tree.h
+++ b/ebtree/eb32tree.h
@@ -129,7 +129,7 @@ static forceinline void __eb32_delete(struct eb32_node *eb32)
}
/*
- * Find the first occurence of a key in the tree . If none can be
+ * Find the first occurrence of a key in the tree . If none can be
* found, return NULL.
*/
static forceinline struct eb32_node *__eb32_lookup(struct eb_root *root, u32 x)
@@ -180,7 +180,7 @@ static forceinline struct eb32_node *__eb32_lookup(struct eb_root *root, u32 x)
}
/*
- * Find the first occurence of a signed key in the tree . If none can
+ * Find the first occurrence of a signed key in the tree . If none can
* be found, return NULL.
*/
static forceinline struct eb32_node *__eb32i_lookup(struct eb_root *root, s32 x)
diff --git a/ebtree/eb64tree.h b/ebtree/eb64tree.h
index 2ab833ff..6d0d0391 100644
--- a/ebtree/eb64tree.h
+++ b/ebtree/eb64tree.h
@@ -129,7 +129,7 @@ static forceinline void __eb64_delete(struct eb64_node *eb64)
}
/*
- * Find the first occurence of a key in the tree . If none can be
+ * Find the first occurrence of a key in the tree . If none can be
* found, return NULL.
*/
static forceinline struct eb64_node *__eb64_lookup(struct eb_root *root, u64 x)
@@ -178,7 +178,7 @@ static forceinline struct eb64_node *__eb64_lookup(struct eb_root *root, u64 x)
}
/*
- * Find the first occurence of a signed key in the tree . If none can
+ * Find the first occurrence of a signed key in the tree . If none can
* be found, return NULL.
*/
static forceinline struct eb64_node *__eb64i_lookup(struct eb_root *root, s64 x)
diff --git a/ebtree/ebimtree.c b/ebtree/ebimtree.c
index 092a0ac8..8a75cd84 100644
--- a/ebtree/ebimtree.c
+++ b/ebtree/ebimtree.c
@@ -23,7 +23,7 @@
#include "ebpttree.h"
#include "ebimtree.h"
-/* Find the first occurence of a key of bytes in the tree .
+/* Find the first occurrence of a key of bytes in the tree .
* If none can be found, return NULL.
*/
REGPRM3 struct ebpt_node *
diff --git a/ebtree/ebimtree.h b/ebtree/ebimtree.h
index 99e75039..4a98c96a 100644
--- a/ebtree/ebimtree.h
+++ b/ebtree/ebimtree.h
@@ -35,7 +35,7 @@
REGPRM3 struct ebpt_node *ebim_lookup(struct eb_root *root, const void *x, unsigned int len);
REGPRM3 struct ebpt_node *ebim_insert(struct eb_root *root, struct ebpt_node *new, unsigned int len);
-/* Find the first occurence of a key of a least bytes matching in the
+/* Find the first occurrence of a key of a least bytes matching in the
* tree . The caller is responsible for ensuring that will not exceed
* the common parts between the tree's keys and . In case of multiple matches,
* the leftmost node is returned. This means that this function can be used to
@@ -89,7 +89,7 @@ __ebim_lookup(struct eb_root *root, const void *x, unsigned int len)
*/
node_bit = ~node_bit + (pos << 3) + 8; // = (pos<<3) + (7 - node_bit)
if (node_bit < 0) {
- /* This surprizing construction gives better performance
+ /* This surprising construction gives better performance
* because gcc does not try to reorder the loop. Tested to
* be fine with 2.95 to 4.2.
*/
diff --git a/ebtree/ebistree.c b/ebtree/ebistree.c
index 222a4375..d3dc0c5e 100644
--- a/ebtree/ebistree.c
+++ b/ebtree/ebistree.c
@@ -22,7 +22,7 @@
#include "ebistree.h"
-/* Find the first occurence of a zero-terminated string in the tree .
+/* Find the first occurrence of a zero-terminated string in the tree .
* It's the caller's reponsibility to use this function only on trees which
* only contain zero-terminated strings. If none can be found, return NULL.
*/
diff --git a/ebtree/ebistree.h b/ebtree/ebistree.h
index e1bcbc70..9c4fd8cb 100644
--- a/ebtree/ebistree.h
+++ b/ebtree/ebistree.h
@@ -38,7 +38,7 @@
REGPRM2 struct ebpt_node *ebis_lookup(struct eb_root *root, const char *x);
REGPRM2 struct ebpt_node *ebis_insert(struct eb_root *root, struct ebpt_node *new);
-/* Find the first occurence of a length string
[PATCH] DOC: Fix typos in different subsections of the documentation
Hi guys, Fix typos found in the design-thoughts, internals and lua-api subsections of the documentation. Note: I split the whole documentation typos patch in 2 to make it more readable but those can be merged if preferred of course. The patch is attached, but if you want to view the diff online, you can check: https://github.com/haproxy/haproxy/compare/master...aerostitch:doc_typos2 Thanks for your help, Joseph From 07cc22e6ddbcce966833aba418cdfef9f69b0e2c Mon Sep 17 00:00:00 2001 From: Joseph Herlant Date: Tue, 13 Nov 2018 19:45:17 -0800 Subject: [PATCH] DOC: Fix typos in different subsections of the documentation Fix typos found in the design-thoughts, internals and lua-api subsections of the documentation. --- doc/design-thoughts/connection-reuse.txt | 2 +- doc/design-thoughts/entities-v2.txt | 2 +- doc/design-thoughts/http2.txt| 4 ++-- doc/design-thoughts/rate-shaping.txt | 2 +- doc/internals/body-parsing.txt | 4 ++-- doc/internals/connection-header.txt | 2 +- doc/internals/entities-v2.txt| 2 +- doc/internals/entities.txt | 2 +- doc/internals/filters.txt| 6 +++--- doc/internals/notes-layers.txt | 6 +++--- doc/lua-api/index.rst| 2 +- 11 files changed, 17 insertions(+), 17 deletions(-) diff --git a/doc/design-thoughts/connection-reuse.txt b/doc/design-thoughts/connection-reuse.txt index 2b92836a..4eb22f6c 100644 --- a/doc/design-thoughts/connection-reuse.txt +++ b/doc/design-thoughts/connection-reuse.txt @@ -202,7 +202,7 @@ The problem analysed below was solved on 2013/10/22 | least with some transport not de-initialized. We might thus need | conn_xprt_close() when conn_xprt_init() fails. | -| The fd should be conditionned by ->ctrl only, and the transport layer by ->xprt. +| The fd should be conditioned by ->ctrl only, and the transport layer by ->xprt. | | - conn_prepare_ctrl(conn, ctrl) | - conn_prepare_xprt(conn, xprt) diff --git a/doc/design-thoughts/entities-v2.txt b/doc/design-thoughts/entities-v2.txt index 8c9eb484..905888e2 100644 --- a/doc/design-thoughts/entities-v2.txt +++ b/doc/design-thoughts/entities-v2.txt @@ -61,7 +61,7 @@ On the accept() side, we probably need to know : - if a data-layer accept() has been performed => possibly 2 bits, to indicate the need to free() -On the connect() side, we need to konw : +On the connect() side, we need to know : - the desire to send a header (eg: send-proxy) - if this header has been sent => maybe both info might be combined diff --git a/doc/design-thoughts/http2.txt b/doc/design-thoughts/http2.txt index eadaaebe..20a5c54c 100644 --- a/doc/design-thoughts/http2.txt +++ b/doc/design-thoughts/http2.txt @@ -117,7 +117,7 @@ frame size minimum. That means slightly more than 16kB of buffer in each direction to process any frame. It will definitely have an impact on the deployed maxconn setting in places using less than this (4..8kB are common). - Also, the header list is persistant per connection, so if we reach the same + Also, the header list is persistent per connection, so if we reach the same size as the request, that's another 16kB in each direction, resulting in about 48kB of memory where 8 were previously used. A more careful encoder can work with a much smaller set even if that implies evicting entries @@ -216,7 +216,7 @@ have dynamic buffer allocation. Thus : - Tx buffers do not exist. We allocate a buffer on the fly when we're ready to - send something that we need to build and that needs to be persistant in case + send something that we need to build and that needs to be persistent in case of partial send. H1 headers are built on the fly from the header table to a temporary buffer that is immediately sent and whose amount of sent bytes is the only information kept (like for PROXY protocol). H2 headers are more diff --git a/doc/design-thoughts/rate-shaping.txt b/doc/design-thoughts/rate-shaping.txt index 255ae4a7..ca094083 100644 --- a/doc/design-thoughts/rate-shaping.txt +++ b/doc/design-thoughts/rate-shaping.txt @@ -63,7 +63,7 @@ This brings us to a very flexible architecture : - 1 list of rule-based checkpoints per backend - 1 list of rule-based checkpoints per server -Each of these lists have a lot of rules conditionned by ACLs, just like the +Each of these lists have a lot of rules conditioned by ACLs, just like the use-backend rules, except that all rules are evaluated in turn. Since we might sometimes just want to enable that without setting any limit and diff --git a/doc/internals/body-parsing.txt b/doc/internals/body-parsing.txt index 45d7034b..be209af6 100644 --- a/doc/internals/body-parsing.txt +++ b/doc/internals/body-parsing.txt @@ -81,7 +81,7 @@ msg.sov : start of value. First character of the header's value in the header msg.sol : start of line. Points to the beginning of the current header line
[PATCH] DOC: fix a few typos in the documentation
Hi guys, This commit deals with a few misspells in the documentation. One point I'm not sure in the following sentence is if the "unsed" should be "used" or "unset" (from doc/SPOE.txt): The engine name must be uniq for a proxy. If no engine name is provided on the SPOE filter line, the SPOE agent name is unsed by default. The patch is attached, but if you want to view the diff online, you can check: https://github.com/haproxy/haproxy/compare/master...aerostitch:doc_typos Thanks for your help, Joseph From a2e89f9e0b17c00222938341f857b1d067abe5af Mon Sep 17 00:00:00 2001 From: Joseph Herlant Date: Tue, 13 Nov 2018 16:55:16 -0800 Subject: [PATCH] DOC: fix a few typos in the documentation This commit deals with a few misspells in the documentation. --- doc/51Degrees-device-detection.txt | 2 +- doc/SPOE.txt | 12 ++-- doc/architecture.txt | 2 +- doc/close-options.txt | 2 +- doc/coding-style.txt | 6 +++--- doc/configuration.txt | 2 +- doc/cookie-options.txt | 2 +- doc/lua.txt| 6 +++--- doc/management.txt | 2 +- doc/peers-v2.0.txt | 6 +++--- doc/peers.txt | 10 +- doc/regression-testing.txt | 4 ++-- 12 files changed, 28 insertions(+), 28 deletions(-) diff --git a/doc/51Degrees-device-detection.txt b/doc/51Degrees-device-detection.txt index c30cb335..381008ae 100644 --- a/doc/51Degrees-device-detection.txt +++ b/doc/51Degrees-device-detection.txt @@ -87,7 +87,7 @@ Here, two headers are created with 51Degrees data, X-51D-DeviceTypeMobileTablet and X-51D-Tablet. Any number of headers can be created this way and can be named anything. 51d.all( ) invokes the 51degrees fetch. It can be passed up to five property names of values to return. Values will be returned in the same -order, seperated by the 51-degrees-property-separator configured earlier. If a +order, separated by the 51-degrees-property-separator configured earlier. If a property name can't be found the value 'NoData' is returned instead. In addition to the device properties three additional properties related to the diff --git a/doc/SPOE.txt b/doc/SPOE.txt index 2b4cc3b5..59cbafe3 100644 --- a/doc/SPOE.txt +++ b/doc/SPOE.txt @@ -146,7 +146,7 @@ found in the SPOE configuration file. All the file is considered to be in the same anonymous and implicit scope. The engine name must be uniq for a proxy. If no engine name is provided on the -SPOE filter line, the SPOE agent name is unsed by default. +SPOE filter line, the SPOE agent name is used by default. 2.2. "spoe-agent" section -- @@ -192,7 +192,7 @@ groups ... Arguments : is the name of a SPOE group. - Groups delcared here must be found in the same engine scope, else an error is + Groups declared here must be found in the same engine scope, else an error is triggered during the configuration parsing. You can have many "groups" lines. See also: "spoe-group" section. @@ -501,7 +501,7 @@ args [name=] ... When the message is processed, if a sample expression is not available, it is set to NULL. Arguments are processed in their declaration order and added in - the message in that order. It is possible to declare named arguements. + the message in that order. It is possible to declare named arguments. For example: args frontend=fe_id src dst @@ -717,7 +717,7 @@ actions. payload. When it is set, the FIN bit must also be set. -Frames cannot exceed a maximum size negociated between HAProxy and agents +Frames cannot exceed a maximum size negotiated between HAProxy and agents during the HELLO handshake. Most of time, payload will be small enough to send it in one frame. But when supported by the peer, it will be possible to fragment huge payload on many frames. This ability is announced during the @@ -1182,7 +1182,7 @@ IMPORTANT NOTE: By default, for a specific stream, when an abnormal/unexpected will disable it for the transaction (request and response). See 'option continue-on-error' to bypass this limitation. -To avoid a stream to wait infinitly, you must carefully choose the +To avoid a stream to wait undefinetly, you must carefully choose the acknowledgement timeout. In most of cases, it will be quiet low. But it depends on the responsivness of your service. @@ -1219,7 +1219,7 @@ following format: fragmented frames, it is the sum of all fragments. * qT : the delay before the request gets out the sending queue. For fragmented frames, it is the sum of all fragments. -* wT : the delay before the reponse is received. No fragmentation +* wT : the delay before the response is received. No fragmentation supported here. * resT : the delay to process the response. No
Re: OCSP stapling with multiple domains
On Sun, Nov 11, 2018 at 2:48 PM Igor Cicimov wrote: > Hi, > > # haproxy -v > HA-Proxy version 1.8.14-1ppa1~xenial 2018/09/23 > Copyright 2000-2018 Willy Tarreau > > I noticed that in case of multiple domains and OCSP setup: > > # ls -1 /etc/haproxy/ssl.d/*.ocsp > /etc/haproxy/ssl.d/star_domain2_com.crt.ocsp > /etc/haproxy/ssl.d/star_domain_com.crt.ocsp > /etc/haproxy/ssl.d/star_domain3_com.crt.ocsp > /etc/haproxy/ssl.d/star_domain4_com.crt.ocsp > > I get OCSP response from haproxy only for one of the domains > domain.com. Tested via: > > $ echo | openssl s_client -connect domain[234].com:443 -tlsextdebug > -status -servername domain[234].com > > Is this expected? > Any comments/ideas regarding this? Further noticed that OCSP code probably does not check the certificates SANs and matches only based on the CN in the subject since the calls to whatever.domain.tld get stapled but to domain.tld do not.
Re: Balance based on network/cpu load
Hi Jessy, We made an opensource feedback agent which you can use if you like, it'll save you the need to make anything: https://www.loadbalancer.org/blog/open-source-windows-service-for-reporting-server-load-back-to-haproxy-load-balancer-feedback-agent/ Aaron West Loadbalancer.org Ltd.
Re: Balance based on network/cpu load
On 13/11/18 9:37 π.μ., Bruno Henc wrote: > Hello, > > > Not sure if there is a direct way to do this, but you can always create a > monitoring process that > will use the haproxy runtime API to MAINT or DRAIN a server until the CPU / > network load drops. So > you have a simple watchdog process which reads the output from your > monitoring tools to decide if a > server needs to be disabled or re-enabled. > Another approach is to use agent-check from haproxy to query a sidecar process on the backend servers. That sidecar process determines, based on various criteria, the load of the server and instructs haproxy to either drain or reduce the percentage of traffic that it gets. Cheers, Pavlos signature.asc Description: OpenPGP digital signature
Re: [PATCH] HTTP 103 response (Early Hints)
On Tue, Nov 13, 2018 at 09:48:03AM +0100, Frederic Lecaille wrote: > Thank you for having pointed out this issue (fixed by this new patch > attached to this mail). Merged, thank you. Willy
Re: [PATCH] HTTP 103 response (Early Hints)
On 11/13/18 7:48 AM, Aleksandar Lazic wrote:
Hi Fred.
Hello Aleksandar,
Sorry to be picky but I still think that there is some missing text in the
documentation, as mentioned before.
http://git.haproxy.org/?p=haproxy.git;a=commitdiff;h=06f5b6435ba99b7a6a034d27b56192e16249f6f0
MINOR: doc: Add information about "early-hint" http-request action.
As I could be wrong, just ignore this mail.
No you are correct.
Thank you for having pointed out this issue (fixed by this new patch
attached to this mail).
Regards,
Fred.
>From ff8504842e81c9c2e8d7d317e50a62c6167b9609 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?=
Date: Tue, 13 Nov 2018 09:42:13 +0100
Subject: [PATCH 5/5] MINOR: doc: fix truncated line.
---
doc/configuration.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index 4750adf8..8cb4671b 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -4100,7 +4100,8 @@ http-request early-hint [ { if | unless } ]
This appends an HTTP header field to this response whose name is specified in
and whose value is defined by which follows the log-format rules
(see Custom Log Format in section 8.2.4). This is particularly useful to pass
- to the client som
+ to the client some Link headers to preload resources required to render the
+ HTML documents.
See RFC 8297 for more information.
--
2.11.0
Re: Balance based on network/cpu load
Hello, Not sure if there is a direct way to do this, but you can always create a monitoring process that will use the haproxy runtime API to MAINT or DRAIN a server until the CPU / network load drops. So you have a simple watchdog process which reads the output from your monitoring tools to decide if a server needs to be disabled or re-enabled. Hope this helps. Best regards, Bruno Henc On 11/13/18 9:27 AM, Jessy van Baal wrote: Hi there! Is there a way that HAProxy 1.8 can balance based on the network or CPU load on the backend servers? Let’s say, a backend server has 90% CPU usage, it gets out of the load balancing pool for a while until it gets stable. Thanks in advance. Yours sincerely, Jessy van Baal
Balance based on network/cpu load
Hi there! Is there a way that HAProxy 1.8 can balance based on the network or CPU load on the backend servers? Let's say, a backend server has 90% CPU usage, it gets out of the load balancing pool for a while until it gets stable. Thanks in advance. Yours sincerely, Jessy van Baal
