The Pulsar Stabilize filter is available to all Pulsar customers—providing greater control over dynamic routing decisions. Users define a threshold that specifies an acceptable level of performance differentiation between available answers. Any answers outside this threshold are removed from the list of eligible answers. Answers within the threshold remain, retaining the order in which they were received from the previous filter, before being processed by the next filter in the Filter Chain configuration.
By default, the filter is configured to stabilize from the lowest value. Retain this setting if comparing latency values across the endpoints (answers). Alternatively, you can enable the Stabilize from Highest Value option which is useful, for example, if you are comparing measured throughput across all endpoints.
When setting the threshold, you have two options: absolute or relative.
- Absolute (default)
Answers are compared against the "best" value and must fall within the defined threshold to be considered acceptable. For example, if the absolute threshold is set to 50, answers within 50ms of the most performant answer are considered to eligible (i.e. within the threshold).
Allows users to define the threshold using a percentage (instead of a hard-set value). For example, if set to 30%, answers within 30% of the most performant answer are considered to be eligible (i.e. within the threshold).
In some specific cases, the Pulsar Stabilize filter offers a unique approach to traffic routing using Pulsar data. For example, a user can factor in additional information such as the cost associated with a specific CDN when compared to another or the need for user traffic to connect to the same CDN consistently when the latency is within an acceptable range.
Below are a few use cases to differentiate between the Pulsar Sort filter and the Pulsar Stabilization filter.
All users routed to the most performant endpoint (Pulsar without Stabilization)
In this example, the basic Pulsar filter is used where there is no stabilization. The answers in the answer list will be sorted in order of most performant to least performant—ensuring all users are sent to the CDN with the lowest latency. The Sticky Shuffle filter provides a fallback if there is no sufficient or recent Pulsar data available.
Consistently distribute users to CDNs within an acceptable range (Pulsar Stabilization)
Here, the stabilization option is configured with a threshold of 100ms. The performance of CDN C is over 100ms worse than the best available option, CDN A. As a result, CDN C is removed from the answer list. CDN B’s performance is within 100ms of CDN A’s and as a result, Pulsar will make no change to their ordering. Users will be be evenly distributed to CDN A or CDN B with each user reaching the same CDN consistently (as defined by the Sticky Shuffle). Once CDN C’s performance reaches an acceptable level, traffic will begin to rebalance between all 3 CDNs.
Route users based on the cost of each CDN (Pulsar Stabilization)
This example introduces the cost filter prior to the Pulsar Stabilization. Here, a cost is associated with each answer and the answer list is sorted from lowest to highest cost value. Next, the Pulsar Stabilization filter is set to remove answers using a relative threshold of 30%. This filter chain configuration sends users to the lowest-cost CDN (unless that CDN is performing poorly). In this example, we can see that all answers are performing within the acceptable threshold, so Pulsar Stabilization does not remove any of the answers and retains the ordering from the cost filter.
For more information, contact the NS1 support team at email@example.com.