For rate limiting with the Rhino SLEE:
-
An administrator creates limiters and assembles them into hierarchies.
-
The administrator connects those limiters to limiter endpoints.
-
RAs and SBBs determine the number of units needed for a particular piece of work.
-
RAs, SBBs, and Rhino code use limiter endpoints to determine if a piece of work can be done (for example, if a message can be processed or sent).
|
Per-node configuration
Some limiter properties can be overridden on a per-node basis (a value set this way is called a per-node value). For example, a rate limiter’s maximum allowed rate could be set differently for different sized machines. Each node always independently maintains the working state of each limiter (counts of units used and so on). |
What are limiters?
A limiter is an object that decides if a piece of work can be done or not. How the decision is made depends on the type of limiter. Limiters are always created and removed "globally". That is, they always exist on all nodes in the cluster.
Limiter names
Each limiter has a name. A limiter’s name must be globally unique within the scope of the Rhino instance.
|
Name character restriction
The limiter name cannot include the "/" character. |
|
See also Limiter Types for details on limiter properties, and Managing Limiters for procedures to create, remove, set properties, inspect, and list limiters. |
Limiter hierarchies
Limiters can optionally be linked to a single parent limiter and/or multiple child limiters. A limiter only allows a piece of work if all of its ancestors (its parent, its parent’s parent, and so on) also allow the work. You configure a hierarchy by setting the parent property on each limiter.
|
|
The limiter hierarchy is the same on all nodes — per-node hierarchies are not possible. (Nor is it possible to create a cycle among parent/child limiters.) |
Bypassing a limiter
All limiters have a bypassed property.
If the flag is true, then the limiter itself takes no part in the decision about allowing work.
If it has a parent, it delegates the question to the parent.
If is doesn’t have a parent, it always allows all work.
Rhino has no concept of enabling or disabling a limiter. Instead, you use the bypassed property.
Default limiter hierarchy
By default Rhino has two limiters, with the following configuration:
| Name | Type | Parent | Bypassed | Configuration |
|---|---|---|---|---|
QueueSaturation |
QUEUE_SATURATION |
<none> |
❌ |
maxSaturation=85% |
SystemInput |
RATE |
QueueSaturation |
✅ |
maxRate=0 timeUnit=seconds depth=1 |
So by default, limiting only happens when the event staging queue is 85% or more full.
Both limiters can be reconfigured as necessary.
QueueSaturation can be removed, but SystemInput cannot (although it doesn’t have to be used for anything).
|
|
See also Listing Limiters and Limiter Hierarchies. |
Limiter endpoints
A limiter endpoint is the interface between code that uses rate limiting, and the rate-limiting system itself. Administrators cannot create limiter endpoints — they are created as part of RA entities and SBBs. The only configuration available for a limiter endpoint is whether or not it is connected to a limiter. Limiter endpoints are not the same as SLEE endpoints — they are different concepts.
Endpoints in RAs and SBBs
RAs and SBBs may have any number of limiter endpoints, and there is no restriction on what they can be used for. Documentation with each RA or SBB should list and explain the purpose of its limiter endpoints. Typical uses include throttling output of messages to external resources and throttling input messages before passing them to the SLEE.
RA "Input" endpoints
The SLEE automatically creates a limiter endpoint named RAEntity/<entityname>/Input for every RA entity.
These endpoints let the SLEE throttle incoming messages from RA entities.
By default each "Input" endpoint is connected to the built-in "SystemInput" limiter, but the administrator can connect or disconnect it to another limiter.
The SLEE will try to use one unit on the "Input" endpoint every time a new activity is started. If the endpoint denies the unit then the SLEE rejects the activity. The SLEE will forcibly use one unit every time the RA passes in an event or ends an activity. This functionality is built into Rhino, and automatically happens for all RA entities, regardless of whether or not they use other limiter endpoints.
|
|
See also Managing Limiter Endpoints, for procedures to list limiter endpoints, connect them to and disconnect them from a limiter, and find which limiter is connected to them. |
What are units?
Units are an abstract concept representing the cost of doing a piece of work. For example, one unit might represent a normal piece of work, so three units indicate a piece of work that needs three times as much processing.
The RA or SBB determines the number of units used for a particular piece of work. Some might be configurable through configuration properties or deployment descriptors. This information should be documented for each individual RA or SBB.
Using units
Code can ask an endpoint "Can I do x units of work?". If the endpoint is connected to a limiter, the limiter will answer yes or no. If the endpoint is not connected to a limiter, the answer is always yes. If the answer is yes, the units are said to have been used. If the answer is no, the units are said to have been rejected.
Code can also tell the endpoint "I am doing x units of work that cannot be throttled". The endpoint passes this message to a limiter if connected (otherwise, it ignores the message). The units in this case are said to have been forcibly used.
Future limiter decisions do not differentiate between units used and those forcibly used. Rhino just counts both as having been "used".
Example
The following diagram illustrates an example rate limiting configuration, with two limiter hierarchies. Incoming traffic from the MSC is limited by the "FromSwitch" limiter and the limiters further up the chain. The Location and SRI services have defined limiter endpoints, which the administrator has connected (directly or indirectly) to the "To HLR" limiter to limit the total rate of requests to the HLR.
