public inbox for pdm-devel@lists.proxmox.com
 help / color / mirror / Atom feed
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


      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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal