|Manuals

Tuning Staged Power by Workload Pattern

The starter values used in the Worked Example on the parent article work for a generic office-style pool. Real workloads vary, and the right configuration depends on your demand pattern, the chosen Pool Mode, and how much idle capacity you can tolerate. This article gives example configurations for five common patterns. Identify the pattern that most closely matches your situation and use its values as a starting point.

Two principles inform the values below:

  • Lower thresholds and shorter delays produce more responsive pools at the cost of more power-cycling activity.
  • Higher thresholds and longer delays minimize power-cycling at the cost of brief delays for users arriving during ramp-up periods.

The Occupancy Threshold values shown across these patterns assume Max Users per Instance is set comfortably above the highest threshold used — typically at the workload’s true per-VM ceiling. As a rule of thumb, set Occupancy Threshold at roughly half to three-quarters of Max Users per Instance. The patterns below assume Max Users per Instance = 10; scale the threshold values proportionally if your per-VM ceiling is different.

Pattern 1: Standard Office Hours

Who it applies to: A pool of desktops used by a workforce on a Mon-Fri schedule with predictable login activity in the morning, steady use through the day, and tail-off in the late afternoon. Typical of corporate desktops, training environments, and back-office workflows.

Recommended Mode: Scheduled if demand is strictly within office hours and the pool can stay off entirely outside them. Both if the pool occasionally absorbs after-hours work and you want on-demand staging to handle that.

Configuration (Breadth First, Max Users per Instance = 10):

Field Value Rationale
Initial Start Count 5 Enough VMs ready at start of day to absorb the morning login wave without users waiting for a VM to power on.
Occupancy Threshold 4 Trip slightly before VMs fill so additional capacity is ready as users continue logging in.
Additional Start Count 2 Add capacity in modest increments to avoid overshooting.
Power Off Threshold 1 A VM with only one user or none is a candidate for consolidation.
Power Off Delay 15 Buffer against brief disconnects and reconnects late in the day.

Configuration (Depth First, Max Users per Instance = 10):

With Depth First, sessions stack on individual VMs in turn, so thresholds trip more sharply. Lower Occupancy Threshold values are appropriate, and Additional Start Count can usually stay at 1.

Field Value
Initial Start Count 2
Occupancy Threshold 3
Additional Start Count 1
Power Off Threshold 1
Power Off Delay 15

Schedule entries:

The 7:30 AM start is intentional — slightly earlier than a nominal 8:00 AM working day so the Initial Start Count baseline is ready before the first users arrive. Match the From and To times to your actual user behavior rather than the official working day.

Days From To
Mon-Fri 7:30 AM 6:30 PM

Exception Dates: Add company holidays, planned office closures, and any other days when the pool should not power on.

Pattern 2: Login Storm — Aggressive Morning Ramp-Up

Who it applies to: A pool that experiences a sharp spike in logins during a narrow window — typical of customer-service teams, support centers, and retail back-office workflows where most of the workforce logs in within 15 to 30 minutes at the start of a shift. Without aggressive scaling ahead of the spike, the last users to arrive wait noticeably longer than the first.

Recommended Mode: Both. Scheduled provides the pre-warmed baseline; on-demand absorbs the variations within the spike.

Initial Start Count is the most important field for this pattern — it determines how many users land on a ready VM versus waiting for one to power on. Size it for the heaviest day of the week, not the average. After one or two weeks of running the configuration, compare actual peak occupancy against Initial Start Count and raise the value if users are still hitting power-on delays.

Configuration (Breadth First, Max Users per Instance = 10):

Field Value Rationale
Initial Start Count 8 Larger baseline than a standard office pool, sized to absorb most of the spike from the first minute.
Occupancy Threshold 3 Trip aggressively — well before VMs fill — so the next wave of capacity is online when users arrive.
Additional Start Count 3 Add multiple VMs per scale-out event so the pool keeps pace with rapid demand growth.
Power Off Threshold 1 Standard — power-off behavior is not the focus of this pattern.
Power Off Delay 20 Slightly longer to avoid power-cycling churn during the chaotic post-spike period when sessions are still settling.

Configuration (Depth First, Max Users per Instance = 10):

Field Value
Initial Start Count 4
Occupancy Threshold 2
Additional Start Count 2
Power Off Threshold 1
Power Off Delay 20

Schedule entries:

Start the schedule 60 to 90 minutes before the peak login window so the baseline is fully online when the first users arrive.

Days From To
Mon-Fri 7:00 AM 5:00 PM

Pattern 3: Cost-Minimized Development Pool

Who it applies to: A pool used sporadically by a small internal team — engineering, QA, design — where users tolerate a 30-90 second wait for a VM to power on, and the cost of paying for idle compute matters more than instant availability.

This pattern accepts the explicit trade-off that the first user of the day will wait for a VM to power on, because the team logs in late enough and sporadically enough that paying for a pre-warmed baseline isn’t justified. If the team grows or usage becomes more consistent, switch to Pattern 1.

Recommended Mode: On Demand. Scheduled and Both are unnecessary because demand has no time-based shape.

Configuration (Breadth First or Depth First, Max Users per Instance = 10):

Field Value Rationale
Occupancy Threshold 8 Allow VMs to fill substantially before powering on additional capacity. New users may briefly land on a fuller VM, which is acceptable for this pattern.
Additional Start Count 1 One additional VM at a time — over-provisioning is expensive and unnecessary here.
Power Off Threshold 2 Power off VMs as soon as they have two or fewer sessions, to consolidate aggressively.
Power Off Delay 5 Short — the priority is freeing up capacity quickly.

Schedule entries: None.

Pattern 4: 24/7 High-Availability Production Pool

Who it applies to: A pool that must always have capacity available — typical of production support workflows, follow-the-sun operations, monitoring teams, and any pool where waiting for a VM to power on is not acceptable.

Recommended Mode: Before defaulting to Scheduled with seven daily entries, consider whether On Demand is simpler. If you do not need the Initial Start Count baseline guarantee (and the pool’s normal occupancy never drops to zero), On Demand without schedule entries achieves nearly the same outcome with much less configuration. Use Scheduled or Both only when the baseline genuinely matters.

Configuration (Breadth First, Max Users per Instance = 10):

Field Value Rationale
Initial Start Count 4 Always-on baseline. Sized for the typical 24-hour low point — usually overnight in the primary time zone.
Occupancy Threshold 3 Trip before VMs fill so the next capacity is ready in advance of need.
Additional Start Count 2 Add capacity quickly enough to keep pace with surges.
Power Off Threshold 1 Standard.
Power Off Delay 30 Long — for an always-on pool, occasional brief power-off events should not happen at all if possible. The longer delay biases toward keeping VMs running.

Configuration (Depth First, Max Users per Instance = 10):

Field Value
Initial Start Count 2
Occupancy Threshold 2
Additional Start Count 1
Power Off Threshold 1
Power Off Delay 30

Schedule entries:

Each schedule entry covers one day, so a 24/7 pool needs seven entries.

Days From To
Monday 12:00 AM 11:59 PM
Tuesday 12:00 AM 11:59 PM
Wednesday 12:00 AM 11:59 PM
Thursday 12:00 AM 11:59 PM
Friday 12:00 AM 11:59 PM
Saturday 12:00 AM 11:59 PM
Sunday 12:00 AM 11:59 PM

Exception Dates: Generally none — this pattern is designed to never go offline. Use exceptions only for planned maintenance windows where the pool should genuinely be unavailable.

Pattern 5: Hybrid In-Office Pool (Tue/Thu Office Days)

Who it applies to: A pool serving a workforce that follows a hybrid working pattern — typically in-office on specific days (commonly Tuesday and Thursday) and working remotely on other days. Demand on office days is high; on remote days it can drop to near zero.

Recommended Mode: Scheduled. The pattern is too binary for Both — there is no meaningful baseline of variation outside office days to absorb.

Configuration: Use the values from Pattern 1: Standard Office Hours, with one adjustment: lower the Initial Start Count by 1-2 if attendance on hybrid office days is consistently lower than full-week office presence would be.

Schedule entries:

Since the pattern excludes Monday, Wednesday, and Friday, configure a separate entry for each office day. If the team’s hybrid pattern shifts to different days (for example, Mon/Wed/Fri), update the entries accordingly.

Days From To
Tuesday 7:30 AM 6:30 PM
Thursday 7:30 AM 6:30 PM

Exception Dates: Holidays falling on Tuesday or Thursday; team-wide remote weeks.

Choosing Between Breadth First and Depth First

The Pool Mode you select before configuring Staged Power On/Off has a meaningful effect on how thresholds behave:

  • Breadth First spreads sessions evenly across powered-on VMs. Per-VM session counts rise gradually as the pool fills, so thresholds should trigger before VMs reach Max Users per Instance.
  • Depth First stacks sessions on individual VMs in turn before using the next VM. Per-VM session counts on the active VM rise quickly, so thresholds can be lower and increments can be smaller.

For most office-style workloads, Breadth First produces a more uniform user experience because the per-VM resource pressure stays balanced across the pool. Depth First is better suited to pools where minimizing the number of running VMs at any given moment is the priority, even at the cost of one VM working harder than the others. See Pooling Strategies for the conceptual background.

Iterating on Your Configuration

After running a configuration for a week or two, compare the actual behavior against expectations:

  • Is the pool failing to scale out at all? Confirm Occupancy Threshold is below Max Users per Instance. If the threshold equals or exceeds the per-VM cap, no amount of tuning will help — VMs refuse new sessions before reaching the threshold.
  • Are users waiting for VMs to power on at predictable times? Raise Initial Start Count for those windows, or lower Occupancy Threshold so additional capacity is provisioned earlier.
  • Are VMs powering on and off frequently in short cycles? Raise Power Off Delay, or widen the gap between Occupancy Threshold and Power Off Threshold to prevent oscillation.
  • Are you paying for idle capacity for long periods? Lower Initial Start Count, raise Power Off Threshold, or shorten Power Off Delay.
  • Are scaling decisions lagging behind demand? Lower Occupancy Threshold so the system reacts earlier, or raise Additional Start Count so each scale-out event adds more capacity.

See Also