ControlUp Automation: Session Resource Optimization

Session optimization is a common challenge, whether you’re managing a Citrix, VMware Horizon, RDS, or WVD environment (or an environment composed of all three). We’ve been working on a approach to attacking the problem, creating scripts and adding triggers to make the result more comprehensive and powerful.

And we’ve done it! These new trigger/script action combos reduces process priority AND session memory consumption. We’re excited to announce that it’s has been added to our Community Triggers. Here’s more detail and best practice for leveraging it.

Session optimization comes in two forms.  Performance-based or capacity-based.  ControlUp can optimize for both.  Performance-based has been demo’ed and shown with the User Input Delay changing process priority during times of contention.  However, capacity based is a low hanging fruit, ripe for the picking.

ControlUp has enabled four community triggers, now available to customers on version 7.4+. To enable these triggers, simply click the Enabled checkbox for those triggers as shown in the screen shot immediately below.

This post will show you how ControlUp designed these triggers step-by-step.

These triggers have been designed to operate in pairs.  There are two pairs, with each having one trigger for enabling resource optimization and one for restoration.

Session Active <–> Disconnected

Trigger Name	State/Record	Filter	Scope	Follow-up Actions	Name/Description
AAS_Session State – Active
AAS_Session State – Disconnected

Session Idle <–> Active

Trigger Name	State/Record	Filter	Scope	Follow-up Actions	Name/Description
AAS_Session State – Idle to Active
AAS_Session State – Active to Idle

About the Triggers:

State/Record and Filter

Green triggers are the restoration of services, Blue are the reduction of resource consumption.  Realistically, there are 2 alternating states with which we are concerned.

Sessions that go from:

Active -> Disconnected & Disconnected -> Active
Active -> Idle & Idle -> Active

The triggers are designed around these 4 scenarios and the scripts have been written to understand these session changes.  This is made possible by ControlUp passing the session state to the script.

Some key points/considerations.

For the primary states, the field “State” value changing to “Active” or “Disconnected” is a major change and we can key in on this singular field for the major state changes (active <-> disconnected).

However, Idle <-> Active Session State is determined by a mix of the field “State” and “Idle Time (Mins)”.

An Idle session has the field “State” as “Active”, but has some value (for instance, 15) in the field “Idle Time (Mins)”.  When the session state field “Active” and field “Idle Time (Mins)” has changed to “0” after exceeding our “Idle” threshold, we consider the state restored to Active from Idle.

Due to the additional qualifier, an Advanced trigger is needed for dealing with the Active -> Idle and Idle -> Active triggers.  A further qualification is needed when going from Idle to Active because we require the additional check that we are in an idle state before considering the state change back to Active.

Scope

It is EXTREMELY recommended that the scope of these triggers target the specific use cases for which they are designed.  Multi-session servers like Citrix XenApp/Virtual Apps, VMWare Horizon View, Microsoft Remote Desktop Services (RDS) or Windows for Virtual Desktops (WVD). Having these triggers target against larger scopes may cause unwanted side effects as admin machines or servers may not have the timeouts nor want the resource reduction effects.

Follow-up Actions

There are two scripts that the triggers will use.  Two scripts are activated when Resource Reduction triggers are fired.  One script is activated when the restoration of services triggers are fired.

The description of each script action is sufficient to describe their purpose:

Script Action Settings

VE Trim Process Working Sets
VE Adjust Process Priority based from Session State

Resource Reduction triggers and script actions

When the resource reduction trigger(s) fire, ControlUp has identified two script actions that have a positive effect in reducing resource consumption.  “VE – Adjust Process Priority based on Session State” and “VE – Trim Process Working Sets”.

Operation – “VE – Trim Process Working Sets”

The script action “VE – Trim Process Working Sets” takes the following parameters:

The two arguments worth modifying or having a user consider modifying is “Working Set Size (MB)” and “Exclude processes”.

“Working Set Size (MB)” – The size of the working set to trim down to. If 0 or negative then the entire working set will be emptied. The Working Set can grow above this as long as a hard limit is not in place.

“Exclude Processes” – A list of processes (without the .exe) separated by a forward slash (eg, “cmd/powershell/winlogon”).  Memory trimming will be skipped for all processes in this list.

To change the list of Excluded Processes, you’ll need to modify the “Exclude Processes” list to add any additional processes.

This script only works in one direction → reduction of memory consumption of processes or processes within a session.  There is no reverse of the purge of the working set.

Operation – “VE – Adjust Process Priority based on Session State”

The script action “VE – Adjust Process Priority based on Session State” takes the following parameters:

The two arguments worth modifying or having a user consider modifying is “Process Priority Floor” and “Excluded processes”.

“Process Priority Floor” – Specifies to what level that a process priority should be reduced.

“Excluded Processes” – A list of processes (without the .exe) separated by a forward slash (eg, “cmd/powershell/winlogon”).  Process Priority will not be changed for processes within this list.

This script works in two directions.  The reduction of process priority and the restoration of process priority.  There is logic within the script to determine what to do with the processes based on the session state.  If the state is active with an idle time that has a value of anything but zero the state is considered Idle.  If the idle time is zero and the session state is active, the session is considered active.  Lastly, if the session state is disconnected, then the session is considered disconnected.

When a session is considered disconnected or idle then process priority will be reduced to the value in the “Process Priority Floor” (excluding all processes in the “Excluded Processes” list).  When a session is considered active, one of two things will occur.  If a list of processes and their previous priority state is found, process priority is set to match the list.  If a list is not found then process priority will be set to “Normal”.