muxer-sdk/autoscaler/dataand is shown below:
path- Path to program, this should take the folder that is uploaded into consideration.
mappings- This maps the files uploaded to the cluster to
muxerscurrent working directory
environment_variables- This sets environment variables of
uptime- configures the parameters for detection of failed
muxersvia metrics. This is achieved by tracking the change of
muxer_uptime_sec. This is updated by Connect and if it's not updated for
thresholdseconds Autoscaler considers the
muxeras crashed and de-spawns it.
locationAvailability zone that the Connect instances reside in. This must match the string passed to the
hadean cluster create --availability-zoneargument. If it doesn't the dynamic scaling will fail. Please check Platform SDK docs for further information.
disk_sizeThe size of the volume created with each instance of Connect . Must meet minimum value for the associated volume type.
locationRegion that the Connect instances reside in. This must match the string passed to the
hadean cluster create --locationargument. If it doesn't the dynamic scaling will fail. Please check Platform SDK docs for further information.
disk_sizeNot applicable for Azure
timeoutTimeout in milliseconds for metric server queries.
allowed_timeoutsA machine will be deallocated from the cluster if this threshold of timeouts is passed.
[scalinglimit]section must be provided. It defines the hard limits on the number of program instances managed by the Autoscaler.
defaultis simply the initial number of program instances that will be spawned when the Autoscaler starts. It is worth keeping in mind that the Autoscaler will begin applying scaling rules immediately after the first client connection - setting a large default will make sense if there a lot of clients "waiting", but if not the Autoscaler will begin despawning instances until the capacity does not exceed demand.
maxis the maximum number of instances that can exist at the same time. The Autoscaler does not explicitly support unbounded scaling, and
maxmust always be provided (but in practice accepts values up to 2^32 - 1).
minis the minimum number of instances that the Autoscaler will maintain; it will not despawn below this limit. Setting this to 0 may cause the situation where all Connect nodes are despawned (and will never be respawned, because clients won't be able to connect).
default == max == mineffectively disables scaling -
defaultinstances will be spawned, and the Autoscaler will never go above or below that value. In this case, the
[scalingrule]section may be omitted.
[scalingrule]section describes how the Autoscaler should spawn and despawn Connect instances. The Autoscaler uses concurrently connected users (CCU) to determine when it should scale up or down. Scaling rule options are described below, you may not need to include all options in your particular case.
instance_capacityis the practical CCU limit of Connect .
headroom_offset- Autoscaler will ensure that at least this capacity is available regardless of the current number of Connect nodes.
headroom_per_instanceAutoscaler will additionally reserve this amount of headroom for every Connect instance that is running.
headroom_hysteresisis used to provide an additional "buffer" when downscaling (to prevent the Autoscaler immediately scaling up again) - it is an additional amount of headroom that must be available in order to despawn a Connect instance. It has the same sharp hysteresis curve as observed with a https://en.wikipedia.org/wiki/Schmitt_trigger.
headroom_per_instance, M is the number of Connect nodes currently 'ready' or 'provisioning', H_c is
headroom_offsetand H_w is
1 instance) +
2 instances) +
headroom_offset= 200. Since there is now a second instance adding 1000 capacity, the next scale-up would be when the 1801st client joins.
2 instances) +
headroom_hysteresis= 210. This equates to there being less than 1790 clients connected.
sleepvalue causes the rule to be ignored if less than
sleepseconds have elapsed since the last time the rule caused a scale up or scale down to occur.
sample.period(seconds) The sampling period for the scaling logic
sample.windowdefines how many of these values should be kept in a sliding window
sample.aggregationdefines how the sliding window as a whole is mathematically reduced to a single value - this value is the one used for controlling the Autoscaler. This is described in a little more detail below.
sample.windowto 1 and
medianeffectively disables this feature:
max- [Recommended] take the highest value in the window (e.g. base the decisions of the Autoscaler on the highest CCU over the last 2 minutes)
min- take the minimum value over the timeframe
mean- use the mean average
median- use the median average
range(the difference between
sum(adds all values) are also supported aggregation methods, but these have limited utility within CCU and the current rule definition format.