From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox Datacenter Manager development discussion
<pdm-devel@lists.proxmox.com>,
Dominik Csapak <d.csapak@proxmox.com>
Subject: Re: [pdm-devel] [PATCH datacenter-manager 1/2] ui: dashboard: increase max-age default to 930 seconds
Date: Fri, 5 Sep 2025 14:26:34 +0200 [thread overview]
Message-ID: <6ed3f4eb-fdce-4693-9099-03a98bf909cd@proxmox.com> (raw)
In-Reply-To: <20250905083253.1242076-1-d.csapak@proxmox.com>
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 <d.csapak@proxmox.com>
> ---
> 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 <t.lamprecht@proxmox.com>
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 <t.lamprecht@proxmox.com>
commit 12ee5033aff25be41d96069c9d2ded8d5f22aa1a
Author: Thomas Lamprecht <t.lamprecht@proxmox.com>
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 <t.lamprecht@proxmox.com>
commit 82f6c1937ca04308d0f44ed54082e2149af746e5
Author: Thomas Lamprecht <t.lamprecht@proxmox.com>
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 <t.lamprecht@proxmox.com>
commit c6c038a9cffc13c34341955c02fe290cfd38d4fe
Author: Thomas Lamprecht <t.lamprecht@proxmox.com>
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 <t.lamprecht@proxmox.com>
_______________________________________________
pdm-devel mailing list
pdm-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pdm-devel
prev parent reply other threads:[~2025-09-05 12:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-05 8:32 Dominik Csapak
2025-09-05 8:32 ` [pdm-devel] [PATCH datacenter-manager 2/2] ui: dashboard: make refresh button force the update Dominik Csapak
2025-09-05 12:26 ` Thomas Lamprecht [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6ed3f4eb-fdce-4693-9099-03a98bf909cd@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=d.csapak@proxmox.com \
--cc=pdm-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.