muxer-sdk/autoscaler/data
and 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 muxers
current working directoryenvironment_variables
- This sets environment variables of muxers
uptime
- configures the parameters for detection of failed muxers
via metrics. This is achieved by tracking the change of muxer_uptime_sec
. This is updated by Connect and if it's not updated for threshold
seconds Autoscaler considers the muxer
as crashed and de-spawns it.location
Availability zone that the Connect instances reside in. This must match the string passed to thehadean cluster create --availability-zone
argument. If it doesn't the dynamic scaling will fail. Please check Platform SDK docs for further information.machine_class
The machine type on AWS for all Connect instances. Please check Platform SDK docs for information about supported values.disk_class
The volume type on AWS for all Connect instances. Please check Platform SDK docs for information about supported values.disk_size
The size of the volume created with each instance of Connect . Must meet minimum value for the associated volume type.location
Region that the Connect instances reside in. This must match the string passed to thehadean cluster create --location
argument. If it doesn't the dynamic scaling will fail. Please check Platform SDK docs for further information.machine_class
The machine size for all Connect instances. Please check Platform SDK docs for information about supported values.disk_class
The storage type for all Connect instances. Please check Platform SDK docs for information about supported values.disk_size
Not applicable for Azuretimeout
Timeout in milliseconds for metric server queries.allowed_timeouts
A 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.default
is 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.max
is the maximum number of instances that can exist at the same time. The Autoscaler does not explicitly support unbounded scaling, and max
must always be provided (but in practice accepts values up to 2^32 - 1).min
is 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 == min
effectively disables scaling - default
instances 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_capacity
is the practical CCU limit of Connect .[scalinglimit]
).headroom_offset
- Autoscaler will ensure that at least this capacity is available regardless of the current number of Connect nodes.headroom_per_instance
Autoscaler will additionally reserve this amount of headroom for every Connect instance that is running.headroom_hysteresis
is 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_offset
and H_w is headroom_hysteresis
instance_capacity
- ((headroom_per_instance
* 1 instance
) + headroom_offset
).headroom_per_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.headroom_per_instance
* 2 instances
) + headroom_offset
+ headroom_hysteresis
= 210. This equates to there being less than 1790 clients connected.despawn_threshold
parameter. If this parameter is set to 0
autoscaler will not despawn any nodes that has connected clients.sleep
value causes the rule to be ignored if less than sleep
seconds 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 logicsample.window
defines how many of these values should be kept in a sliding windowsample.aggregation
defines 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.period
and sample.window
to 1 and sample.aggregation
to max
, min
, mean
, or median
effectively 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 timeframemean
- use the mean averagemedian
- use the median averagerange
(the difference between min
and max
) and sum
(adds all values) are also supported aggregation methods, but these have limited utility within CCU and the current rule definition format.