Rhino comes with the following types of limiters:

Rate limiter

Rate limiters limit the rate of work. It is typically used to limit the rate of incoming events, or outgoing requests.

Type Name

RATE
(the type argument specified when creating a limiter)

Rejects work when…​

the number of units used (or forced) during a given timeUnit exceeds maxRate. TimeUnit can be one second, one minute, one hour, or one day (24-hour period, not calendar day).

Rhino implements rate limiters with a token bucket algorithm, where the depth property determines the bucket size. The actual bucket size is maxRate * depth.

The default setting for depth is 1.0. So "50/sec" means "allow for 50 per second". When depth is 2, "50/sec" means "allow an initial burst of 100 and then 50 per second." The recommended setting for maxRate is where your CPU is around 85%.

Example

Configured as "maxRate=100.0 timeUnit=seconds depth=2.0", the limiter has a bucket size of 100.0*2.0=200.0. If the bucket is empty when the limiter becomes overloaded, it allows 200+100=300 units in the first second and then 100 units per second after that.

Example

Configured as "maxRate=0.1 timeUnit=seconds depth=10.0", the limiter has a bucket size of 0.1*10.0=1.0. If the bucket is empty when the limiter becomes overloaded, it allows 1.0+0.1=1 units in the first second and then 1 units per 1/maxRate seconds after that.

Properties

Property Legal values Default Settable per node
 bypassed

true false

 false

 parent

name of another limiter or "" for no parent

 ""

 maxrate

1.0 ⋯ 10000000.0

 0.0

 depth

0.01 ⋯ 00.0

 1.0

 timeunit

seconds minutes hours days
Note that 'days' means 24 hour periods, not calendar days.

 seconds

Queue-saturation limiter

The queue-saturation limiter rejects work when the event-staging queue (explained in the Staging section) passes a given saturation. It provides some overload protection, by limiting incoming activities in cases where too much work is backlogged, while allowing enough headroom to process existing activities.

For example, the default configuration has the QueueSaturation limiter configured with an allowed capacity of 85%. With the default maximum queue size of 3000, this limiter starts rejecting new activities when 2250 or more items are in the queue (leaving 15% headroom for processing existing activities).

Type Name

QUEUE_SATURATION
(the type argument specified when creating a limiter)

Rejects work when…​

the number of items in the staging queue reaches maxSaturation, expressed as a percentage of the queue’s capacity.

Example

Configured as maxSaturation=80.0 and a queue capacity of 200, the limiter will reject work when the queue contains 160 or more items.

Properties

Property Legal values Default Settable per node
 bypassed

true false

 false

 parent

name of another limiter or "" for no parent

 ""

 maxSaturation

0.0 ⋯ 100.0

 0

Absolute stat limiter

The absolute stat limiter rejects work based on the value of a single gauge-type statistic and supports progressive levels of limiting tiers.

This limiter type should be used in cases where a single parameter set gauge can be compared against one or more fixed values to determine if work load should be limited. On each request for one or more units, the current value of the specified statistic is compared against one or more absolute values. Each absolute value can be configured to limit a different percentage of the total unit requests. The absolute value tiers can be structured in such a way as to progressively limit an increasing percentage of all unit requests as the value of the statistic approaches some known threshold.

Tip Only gauge-type statistics are currently supported. Configuring a limiter with a counter or sample-type statistic will cause the limiter to raise a misconfiguration alarm. Any unit requests made to this limiter while it is misconfigured will be accepted (unless rejected by a parent limiter).

Type Name

ABSOLUTE_STAT
(the type argument specified when creating a limiter)

Rejects work when…​

the value of the monitored statistic is equal to or greater than the value of one of the configured limiter tiers that has a non-zero limit percentage.

Example

Configured as

parameterSet=Activities
statistic=active
tiers=[ {10000: 50%} {12000: 75%} {13000: 100%} ]

when the current value of the active gauge in the Activities parameter set is equal to or greater than:

  • 10000 — 50% of all unit requests will be refused;

  • 12000 — 75% of all unit requests will be refused; or

  • 13000 — 100% of all unit requests will be refused.

Properties

Property Legal values Default Settable per node
 bypassed

true false

 false

 parent

name of another limiter or "" for no parent

 ""

 parameterSet

a registered parameter set

 "unspecified"

 statistic

a statistic in the configured parameter set

 "unspecified"

 tiers

one or more mappings of value to limit percentage

 []

Relative stat limiter

The relative stat limiter rejects work based on the values of two related gauge-type statistics and supports progressive levels of limiting tiers.

This limiter type should be used in cases where two related parameter set gauges can be compared against each other to determine if work load should be limited. On each request for one or more units, the current value of the specified statistic is compared against one or more percentage values of the current value of the relative statistic. Each percentage value can be configured to limit a different percentage of the total unit requests. The relative percentage tiers can be structured in such a way as to progressively limit an increasing percentage of all unit requests as the value of the statistic approaches a known threshold with respect to the value of the related statistic.

Tip Only gauge-type statistics are currently supported. Configuring a limiter with a counter or sample-type statistic will cause the limiter to raise a misconfiguration alarm. Any unit requests made to this limiter while it is misconfigured will be accepted (unless rejected by a parent limiter).

Type Name

RELATIVE_STAT
(the type argument specified when creating a limiter)

Rejects work when…​

the value of the monitored statistic is equal to or greater than the relative percentage of the relative statistic as configured in one or more tiers that has a non-zero limit percentage.

Example

Configured as

parameterSet=MemDB-Local
statistic=committedSize
relativeParameterSet=MemDB-Local
relativeStatistic=maxCommittedSize
tiers=[ {75%: 50%} {80%: 75%} {90%: 100%} ]

when the current value of the committedSize gauge in the MemDB-Local parameter set is equal to or greater than:

  • 75% of maxCommittedSize — 50% of all unit requests will be refused;

  • 80% of maxCommittedSize — 75% of all unit requests will be refused; or

  • 90% of maxCommittedSize — 100% of all unit requests will be refused.

Properties

Property Legal values Default Settable per node
 bypassed

true false

 false

 parent

name of another limiter or "" for no parent

 ""

 parameterSet

a registered parameter set

 "unspecified"

 statistic

a statistic in the configured parameter set

 "unspecified"

 relativeParameterSet

a registered parameter set

 "unspecified"

 relativeStatistic

a statistic in the configured relative parameter set

 "unspecified"

 tiers

one or more mappings of relative percentage to limit percentage

 []

Note For the stat limiters, when limiting work in a percentage limit tier, the limiter always attempts to keep the percentage of units rejected as close to the specified limit percentage as possible. For example, upon entering a tier configured to limit 50%, if one unit is requested and accepted, then the next unit will be rejected. If a single request for five units is rejected, then around five of the next requests for a single unit will be accepted. When the limiter drops below a certain tier, or the total units requested while limiting surpasses Integer.MAX_VALUE, that tier’s internal running count of total units requested to units rejected is reset.
Previous page Next page
Rhino Version 3.2