Tip: Staggering Downloads AND Start Times

Content Authoring
1

I’ve seen this asked many times in many ways in this forum. My use case is that I want to set an action with a constraint to start sometime in the future, start the downloads sooner, but also stagger the downloads over time so that all of my clients are not downloading at once and overwhelming a network or SAN connection.

Using an “Stagger action start times” will stagger the execution, but using “Start downloads before constraints are met” means every client will begin the downloads immediately. Using “Stagger action start times” and clearing “Start downloads before constraints are met” means the clients won’t download anything until the start time arrives (and may extend the time required to update them).

I’m trying out the following relevance which appears to accomplish what I want:

not exists actions whose (now < local time (value of header "action-start-time" of it) - (60 + computer id mod 60) * minute )

Applied as Fixlet/Baseline Relevance, there is no “action” so this returns true (showing correct relevance results for the Fixlet/Baseline)
When an Action is taken, if an “Action start time” is specified, the clients will not become Relevant until some time between one and two hours before the action start time. So the clients can start their downloads in a staggered way, and still have the downloads cached before the action start time arrives.
If no “Action start time” is specified, the clients become Relevant immediately and download/execute the action with no stagger.

If the Action has an action start time, and is targetted dynamically, the client does not report back until the 60-120 minute pre-start stagger arrives. If the action is targetted statically, the clients report back “Not Relevant” until the pre-start stagger, then the client will go ahead and start downloading, and execute the action when the start time arrives.

Edit: You do seem to need to configure “Reapply the action whenever it becomes relevant again” to get the action to download & run later after initially reporting Not Relevant.

Edit: The “action-start-time” header on the client shows up with no time zone set and doesn’t appear to be timezone-aware. I’m coercing it to local time zone on the client, but if the Action is sent with a UTC time such as Fri, 24 Mar 2017 13:00:00 -0000, the client will still see the header as “Fri, 24 Mar 2017 13:00:00” regardless of the client’s time zone.

Edit: The timezone issue can be overcome by always sending actions with start time set in UTC, and using the relevance
not exists actions whose (now < universal time (value of header "action-start-time" of it) - (60 + computer id mod 60) * minute ) in the fixlet.

2 Likes
2

Thanks Jason, I also have a similar use case and am excited to try this out in our environment.

1 Like
3

I like the relevance you came up with using not exists instead of using if/then/else like I am currently using for something related. I’ll have to play with that.

4

I’m testing out an update now. This one should handle local vs UTC time in the action settings…

not exists actions whose (now < (if exists (header "action-use-utc" of it) whose (value of it = "1") then (universal time (value of header "action-start-time" of it)) else (local time (value of header "action-start-time" of it))) - (60 + computer id mod 60) * minute )

If a start time is set in the Action, using either local or UTC time, the client will wait until 60 to 120 minutes (depending on its own client id) before the action start time to become relevant and start downloads for the action. This depends on the “Reapply whenever it becomes relevant again” behavior to toggle between Non-Relevant and Relevant.

If no action start time is specified, the client is immediately relevant and starts processing the action.