Configuring Pulsar in the NS1 filter chain is in practice very similar to our other filter options.
Step 1 Add the Pulsar filter into your record’s filter chain.
Note: The Pulsar filter is often placed directly after another sorting filter to ensure that the behavior will fail over to a different routing strategy if there isn’t sufficiently abundant or recent Pulsar data. In this case the Geotarget Country filter will sort the answers before the Pulsar filter. If Pulsar does not have sufficient data for the requester, it will do nothing and the Geotarget ordering will be retained.
Step 2 Assign Pulsar metadata to each of your answers. In this example each answer has been associated with a different CDN.
Once your Pulsar record begins making real-time decisions you can click over to the decisions tab under the Pulsar menu to view how the record is performing.
When configuring a DNS record to use Pulsar, users are given a series of options that will modify the behavior of the Filter Chain. These options can be enabled at the answer level by editing the Pulsar job metadata.
Granularity type establishes the criteria which will be considered when making a Pulsar decision. Information processed by Pulsar is collected in regards to the data point’s geographical location as well as the Autonomous System Number (ASN) of its origin.
Geo+ASN routes based on measurements taken from users on the same ASN in the same geographical region, e.g. performance of users in New York on Verizon Wireless to all Pulsar-enabled answers.
Geo routes based solely on geographical measurements, e.g. performance of users in Germany to all Pulsar-enabled answers.
Selecting both options will use Geo+ASN by default. In cases where there is not enough data, Pulsar will automatically fall back to Geo. This is the recommended configuration.
Pulsar has the ability to make routing decisions based on a resource's availability threshold. If a resource is determined to not meet the configured threshold, Pulsar will not serve it in the region/ASN of the collected data. Historical availability data can be viewed in the ‘Availability’ tab of the Pulsar UI.
What this means to you: e.g. CDN 1 is having an outage in Europe but has excellent availability in US-East. CDN 2 has low latency in Europe but high latency in US-East. Pulsar is able to identify the outage and serve CDN 2 in Europe while serving CDN 1 in US-East.
The Pulsar filter’s configuration option “Apply Availability Threshold” has a simple on/off switch and a threshold. If you’d like to use this feature, simply turn on the threshold and enter a value that you’ve determined best meets your business needs.
Pulsar also allows you to apply bias to a certain answer. Users can add, subtract, or adjust values by a multiplier to determine the extent a certain answer will gain bias.
* +20 will add 20ms * -15 will subtract 15ms * 130% will adjust the value to 1.3x * 80% will adjust the value to 0.8x
For example, let's say a customer is using CDN A and CDN B, and because of cost, they would prefer to use CDN A unless CDN B performs at least 15 ms faster. In this case the user can add ‘+15’ to the CDN B job for a certain answer. Now, if Pulsar determines CDN B latency is 20ms and CDN A is 30ms, CDN A will be chosen because it’s more performant than the base 20ms + the 15ms added in biasing.
If you have any questions about configuring Pulsar to best achieve your goals send us an e-mail at [email protected].