From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <pbs-devel-bounces@lists.proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id A22FA1FF173 for <inbox@lore.proxmox.com>; Thu, 1 Aug 2024 15:14:44 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id ED7BE353D1; Thu, 1 Aug 2024 15:14:47 +0200 (CEST) Message-ID: <01c52f25-a04d-4dbb-b651-ac7085964b1b@proxmox.com> Date: Thu, 1 Aug 2024 15:14:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Christian Ebner <c.ebner@proxmox.com> To: Proxmox Backup Server development discussion <pbs-devel@lists.proxmox.com>, Dominik Csapak <d.csapak@proxmox.com> References: <20240723100448.1571064-1-d.csapak@proxmox.com> <e331df36-3532-4360-8f58-f0438f4a8d73@proxmox.com> Content-Language: en-US, de-DE In-Reply-To: <e331df36-3532-4360-8f58-f0438f4a8d73@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.022 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] [PATCH proxmox-backup] fix #5622: backup client: properly handle rate/burst parameters X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion <pbs-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>, <mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/> List-Post: <mailto:pbs-devel@lists.proxmox.com> List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>, <mailto:pbs-devel-request@lists.proxmox.com?subject=subscribe> Reply-To: Proxmox Backup Server development discussion <pbs-devel@lists.proxmox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: pbs-devel-bounces@lists.proxmox.com Sender: "pbs-devel" <pbs-devel-bounces@lists.proxmox.com> On 8/1/24 14:44, Christian Ebner wrote: > On 7/23/24 12:04, Dominik Csapak wrote: >> the rate and burst parameters are integers, so the mapping from value >> with `.as_str()` will always return `None` effectively never >> applying any rate limit at all. >> >> To fix it, just map from u64 to HumanByte. >> >> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com> >> --- > > Did some tests on this and while the rate limit gets applied, the burst > value does not seem to be honored for my case. Am I misinterpreting the > burst parameter or is there still an underlying issue? > > Here is what was tested: > - Monitor network throughput to localhost by running `tcpsubnet-bpfcc > 127.0.0.1/32` as well as `iftop` (got only low additional traffic noise > without invoking the proxmox-backup-client). > - Before each proxmox-backup-client invocation, the chunks and snapshots > were deleted from the datastore to have similar conditions. > - Backup using proxmox-backup-client to local datastore via localhost by > running `proxmox-backup-client backup usr.pxar:/usr --rate=100000`, rate > limit is now honored as expected! > - `proxmox-backup-client backup usr.pxar:/usr --rate=100000 > --burst=1000000000000`, expected to reach much higher initial burst > throughput because of the huge bucket size, but rate is limited to the > same rate as above already from the beginning. > - Without rate limit, much higher rates can be reached, so that is not > the limiting factor. Ah, I see the bucket starts empty, so this is expected then. _______________________________________________ pbs-devel mailing list pbs-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel