Re: Odd bwlim Behavior
One other detail: we're on the latest 2.8.2 version. — Luke Seelenbinder Stadia Maps | Founder & CEO stadiamaps.com > On Sep 2, 2023, at 15:56, Luke Seelenbinder > wrote: > > Hi List, > > I wanted to ask about an unexpected behavior I'm observing with the bandwidth > limit filter. I'm not sure if it's a bug, a misconfiguration, or if I'm just > misunderstanding. > > Config: > > peers > > table bw-by-src type ipv6 size 25k expire 1h store > bytes_out_rate(10s) > > frontend > > # Bandwidth filters > # Limit to 50MB/10s > filter bwlim-out by-srckey src table pop_local/bw-by-src limit > 50m > # Limit other to 100MB/10s (temporarily higher limits) > filter bwlim-out other-by-src key src table pop_local/bw-by-src limit > 100m > http-request set-bandwidth-limit by-src if > is_first_thing > http-request set-bandwidth-limit other-by-src if > is_other_thing > > With this configuration, 99% of requests succeed, but approximately 1% of > requests, especially requests made in isolation hang forever. The average > payload in this config is between 50-100kB / request, but some requests would > be quite small (< 1kB) or quite large (> 500kB). > > For example, a standard curl GET request returns the headers, but never the > body (at least not in the first few seconds). We have a mix of HTTP/1.1, H2, > and H3 front-end connections, with HTTP/1.1 on the backend. > > Does the 10s period create a problem? (The goal with that is to allow > temporary bursts especially at initial connection with an average limit.) Do > I need to add min-size (reading the code doesn't seem to imply it would help)? > > I may be misreading the docs, and it's just a bogus configuration. :) > > Thanks in advance for any help or ideas you all have! > > Best, > Luke > > — > Luke Seelenbinder > Stadia Maps | Founder & CEO > stadiamaps.com >
Odd bwlim Behavior
Hi List, I wanted to ask about an unexpected behavior I'm observing with the bandwidth limit filter. I'm not sure if it's a bug, a misconfiguration, or if I'm just misunderstanding. Config: peers table bw-by-src type ipv6 size 25k expire 1h store bytes_out_rate(10s) frontend # Bandwidth filters # Limit to 50MB/10s filter bwlim-out by-srckey src table pop_local/bw-by-src limit 50m # Limit other to 100MB/10s (temporarily higher limits) filter bwlim-out other-by-src key src table pop_local/bw-by-src limit 100m http-request set-bandwidth-limit by-src if is_first_thing http-request set-bandwidth-limit other-by-src if is_other_thing With this configuration, 99% of requests succeed, but approximately 1% of requests, especially requests made in isolation hang forever. The average payload in this config is between 50-100kB / request, but some requests would be quite small (< 1kB) or quite large (> 500kB). For example, a standard curl GET request returns the headers, but never the body (at least not in the first few seconds). We have a mix of HTTP/1.1, H2, and H3 front-end connections, with HTTP/1.1 on the backend. Does the 10s period create a problem? (The goal with that is to allow temporary bursts especially at initial connection with an average limit.) Do I need to add min-size (reading the code doesn't seem to imply it would help)? I may be misreading the docs, and it's just a bogus configuration. :) Thanks in advance for any help or ideas you all have! Best, Luke — Luke Seelenbinder Stadia Maps | Founder & CEO stadiamaps.com
[PATCH] MINOR: properly mark the end of the CLI command in error messages
Hello all, this is a patch related to correctly marking the end of the CLI command in the error message in several places in the file src/ssl_ckch.c . -- Miroslav ZagoracFrom f3d8570a7872f1be4fe0e6d20d278c9397813f21 Mon Sep 17 00:00:00 2001 From: Miroslav Zagorac Date: Fri, 1 Sep 2023 22:23:27 +0200 Subject: [PATCH] MINOR: properly mark the end of the CLI command in error messages In several places in the file src/ssl_ckch.c, in the message about the incorrect use of the CLI command, the end of that CLI command is not correctly marked with the sign ' . --- src/ssl_ckch.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/src/ssl_ckch.c b/src/ssl_ckch.c index 341531d17..07a04aa18 100644 --- a/src/ssl_ckch.c +++ b/src/ssl_ckch.c @@ -2260,7 +2260,7 @@ static int cli_parse_commit_cert(char **args, char *payload, struct appctx *appc return 1; if (!*args[3]) - return cli_err(appctx, "'commit ssl cert expects a filename\n"); + return cli_err(appctx, "'commit ssl cert' expects a filename\n"); /* The operations on the CKCH architecture are locked so we can * manipulate ckch_store and ckch_inst */ @@ -2328,7 +2328,7 @@ static int cli_parse_set_cert(char **args, char *payload, struct appctx *appctx, return 1; if (!*args[3] || !payload) - return cli_err(appctx, "'set ssl cert expects a filename and a certificate as a payload\n"); + return cli_err(appctx, "'set ssl cert' expects a filename and a certificate as a payload\n"); /* The operations on the CKCH architecture are locked so we can * manipulate ckch_store and ckch_inst */ @@ -2667,7 +2667,7 @@ static int cli_parse_set_cafile(char **args, char *payload, struct appctx *appct add_cmd = 1; if (!*args[3] || !payload) - return cli_err(appctx, "'set ssl ca-file expects a filename and CAs as a payload\n"); + return cli_err(appctx, "'set ssl ca-file' expects a filename and CAs as a payload\n"); /* The operations on the CKCH architecture are locked so we can * manipulate ckch_store and ckch_inst */ @@ -2776,7 +2776,7 @@ static int cli_parse_commit_cafile(char **args, char *payload, struct appctx *ap return 1; if (!*args[3]) - return cli_err(appctx, "'commit ssl ca-file expects a filename\n"); + return cli_err(appctx, "'commit ssl ca-file' expects a filename\n"); /* The operations on the CKCH architecture are locked so we can * manipulate ckch_store and ckch_inst */ @@ -3368,7 +3368,7 @@ static int cli_parse_set_crlfile(char **args, char *payload, struct appctx *appc return 1; if (!*args[3] || !payload) - return cli_err(appctx, "'set ssl crl-file expects a filename and CRLs as a payload\n"); + return cli_err(appctx, "'set ssl crl-file' expects a filename and CRLs as a payload\n"); /* The operations on the CKCH architecture are locked so we can * manipulate ckch_store and ckch_inst */ @@ -3471,7 +3471,7 @@ static int cli_parse_commit_crlfile(char **args, char *payload, struct appctx *a return 1; if (!*args[3]) - return cli_err(appctx, "'commit ssl ca-file expects a filename\n"); + return cli_err(appctx, "'commit ssl ca-file' expects a filename\n"); /* The operations on the CKCH architecture are locked so we can * manipulate ckch_store and ckch_inst */ -- 2.42.0
