The Pulsar Stabilization filter is a feature of NS1’s Pulsar offering that delivers greater control over dynamic routing decisions. By utilizing real time telemetry data, Pulsar can operate in two modes. The first leverages the original Pulsar filter to sort answers from “best” to “worst” by the chosen performance metric as defined by the user. The second leverages the Pulsar Stabilization filter, where a threshold can be defined to characterize an acceptable level of performance differentiation between available answers. While stabilization is active, any answers outside of this threshold will be removed. Answers within the threshold are kept and retain their order from the previous filter.
Define the threshold in the filter chain options:
The default is to stabilize from the lowest value. This is most commonly used when comparing latency. Enabling ‘Stabilize from highest value’ will pin the threshold to the highest value. This could be used for throughput, for example.
‘Absolute’ is the default way to define the threshold. It is the value an answer will need to be within, when compared to the ‘best’ value, to be considered acceptable. For example, if set to 50, answers within 50ms of the most performant answer would be considered to be inside the acceptable threshold.
‘Relative’ is an alternative to ‘Absolute’. Instead of a set value to define the threshold, ‘Relative’ uses a percentage value. For example, if set to 30%, answers within 30% of the most performant answer would be considered to be inside of the threshold.
There are some specific cases where the Pulsar Stabilization filter offers unique ways to route on 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 filter and the Pulsar Stabilization filter.
All users routed to the most performant endpoint (Pulsar without Stabilization)
In this example the Pulsar Filter is being used which does not employ any 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 is added as the fall back behavior if sufficiently good or recent Pulsar data is not 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%, meaning any answer with a performance difference worse than 30% of the most performant answer. This filter chain configuration is used so that users will be sent 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, and therefore Pulsar Stabilization does not remove any of the answers and retains the ordering from the Cost Filter.
If you have any questions about Pulsar Stabilization or Pulsar in general, reach out to our support team at [email protected].