From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id B08F61FF15C for ; Fri, 5 Sep 2025 14:26:50 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id A410C14485; Fri, 5 Sep 2025 14:27:07 +0200 (CEST) Message-ID: <6ed3f4eb-fdce-4693-9099-03a98bf909cd@proxmox.com> Date: Fri, 5 Sep 2025 14:26:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta To: Proxmox Datacenter Manager development discussion , Dominik Csapak References: <20250905083253.1242076-1-d.csapak@proxmox.com> Content-Language: en-US From: Thomas Lamprecht In-Reply-To: <20250905083253.1242076-1-d.csapak@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1757075176531 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.030 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 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [mod.rs] Subject: Re: [pdm-devel] [PATCH datacenter-manager 1/2] ui: dashboard: increase max-age default to 930 seconds X-BeenThere: pdm-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Datacenter Manager development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox Datacenter Manager development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pdm-devel-bounces@lists.proxmox.com Sender: "pdm-devel" Am 05.09.25 um 10:32 schrieb Dominik Csapak: > our backend refreshes the metrics with a 15 minute interval, so > using a lower max-age will always refresh it then which is not the point > of the caching mechanism. > > Use a slightly higher value than 15 minutes so we mostly use the cached > information. > > Signed-off-by: Dominik Csapak > --- > ui/src/dashboard/mod.rs | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/ui/src/dashboard/mod.rs b/ui/src/dashboard/mod.rs > index cfee55b..9d65122 100644 > --- a/ui/src/dashboard/mod.rs > +++ b/ui/src/dashboard/mod.rs > @@ -55,7 +55,8 @@ mod tasks; > use tasks::TaskSummary; > > /// The default 'max-age' parameter in seconds. > -pub const DEFAULT_MAX_AGE_S: u64 = 60; > +// backend refreshes resources every 15 minutes so use that +30 seconds as a buffer > +pub const DEFAULT_MAX_AGE_S: u64 = 930; > > /// The default refresh interval > pub const DEFAULT_REFRESH_INTERVAL_S: u64 = DEFAULT_MAX_AGE_S / 2; Thanks for this series, while I initially suggested this argument I found it not really good when rethinking it, so I tried to implement a better logic that differs first load and successive ones. Also went a slightly different route for the force-reload, both implementation wise and behavior wise. I tried to put in some rationale in the commits implementing this, they already got pushed and are: commit 50d0908c39c357b1b76fd12e1a56e33f29239c0b Author: Thomas Lamprecht Date: Fri Sep 5 14:17:34 2025 +0200 ui: dashboard: make reload button do a reload with low max-age Which forces a reload, but not make this a hard cut by using zero max-age, as that doesn't ensures real time data either (it will be always some 10 to 100ms old) but rather allow it to be at max 3s old. This ensures that high-frequent reload button clicks (also from other users) do not result in a overload/DOS of the remotes. Signed-off-by: Thomas Lamprecht commit 12ee5033aff25be41d96069c9d2ded8d5f22aa1a Author: Thomas Lamprecht Date: Fri Sep 5 12:11:27 2025 +0200 ui: dashboard: trigger normal reload directly after initial high-max-age load With this and the previous commit users should get best of both worlds, for one seeing some (maximal 15 minute old) data quickly at first render while then getting current data ASAP. Signed-off-by: Thomas Lamprecht commit 82f6c1937ca04308d0f44ed54082e2149af746e5 Author: Thomas Lamprecht Date: Fri Sep 5 11:59:03 2025 +0200 ui: dashboard: use high max-age for initial load Use the same interval as the backend's cache polling task to try to ensure we get data shown to the user fast, as otherwise it's rather bad UX if (some) remotes are rather slow. It's planned to trigger a update with the actual configured polling interval directly afterwards in a future commit, but this change itself makes sense on it's own. Signed-off-by: Thomas Lamprecht commit c6c038a9cffc13c34341955c02fe290cfd38d4fe Author: Thomas Lamprecht Date: Fri Sep 5 11:30:25 2025 +0200 ui: dashboard: rework default refresh and max-age interval values Lower the default max age to 30s, which is a somewhat good default for when having the dashboard open for a prolonged time. Note that I plan to special case the first load with a higher value in a future commit to avoid having to compromise to much here. Actually lower the default refresh interval, as querying itself is cheap, at least if the backend's cache age is new enough, and doing that more often while keeping a higher max-age ensures we profit from any actual data update, be it those from the backend's polling task or those from force-reloads from other updates. Also add some rationale to the doc comments, in the end this is naturally still chosen by gut-feeling and cannot really be derived with a objective and logical deduction. Signed-off-by: Thomas Lamprecht _______________________________________________ pdm-devel mailing list pdm-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pdm-devel