Configure this sub-rule to control how to handle responses to requests when your origin or third-party entities are slow, or even down. This can help minimize a negative impact on user experience.
Optional (This is only applicable if you enable Site Failover.)
This rule lets you simulate an origin connection problem and test your Site Failover configuration on Akamai's staging network.
This rule's Criteria is a little complex. Once all of its settings are met, the Break Forward Connection behavior is applied. Here's an example of how it works:
A request comes in for your property.
To start, the rule's "If" argument will only apply if the request is served through the Akamai staging network. If you've promoted your property to Production, this rule won't apply.
The rule will also check a request for a
Requestheader that includes the
breakconnectionentry that's set to
Your-Secret-Here. So, you need to ensure a request to activate this rule includes this header.
With both Criteria met, the Break Forward Connection behavior is applied. This simulates an origin connection problem, so you can test what you've got set up for the Site Failover sub-rule.
You don't actually need to do anything with this sub-rule. It only applies if you enable Site Failover. Also, it's only used for testing and has no bearing on the regular delivery of your Ion content. If you want to use it, understand that the
Your-Secret-Hereis here as a placeholder. You can leave it here and use it in the
breakconnectionentry, but we recommend that you provide a unique, custom value in its place.
Use this rule to decide how edge servers should respond when your origin server isn't available.
You can set the "If" argument for this rule to one of two settings:
Origin Timeout (default). Set to yes. This will match on requests when the origin fails to respond due to a Transmission Control Protocol (TCP) timeout. The length of this timeout can vary, based on the type of origin server you have in place.
Response Status Code. Use this criterion to match on requests based on the HTTP response code that's served to the client.
You can select from several different failover actions. These aren't unique to Ion. See the help for this behavior in the Property Manager documentation for information on each.
If you enable Site Failover, we recommend that you test it using the Simulate Failover sub-rule. To do so:
Review how the Simulate Failover is set up. Specifically, you need the value set for the Request Header portion of the Criteria. This defaults to
Get set up for testing. Specifically, you need to activate your Ion property on Akamai's staging network.
Make a request to your property hostname. The request needs to include the
Requestheader that includes the
breakconnectionentry that's set to the value noted in step 1.
This will apply the Simulate Failover rule, which creates a breaking condition and applies what you've set here for Site Failover.
This rule helps you monitor the health of your origin by tracking unsuccessful IP connection attempts. This can be useful if you want to reduce the number of hits to your origin when the IP addresses used to access it are faulty or unavailable.
For more details on this behavior and its use, see the Property Manager documentation for it.
The Origin Health Detection behavior in this rule has been preconfigured with best practices settings. While you can change them, these are the settings we recommend.
|Field||Default Ion setting||Sub-options|
edge servers will mark an IP address associated with your origin as faulty after this number of consecutive connection failures.
|Retry Interval||10 (seconds)||An edge server will wait this number of seconds before trying to reconnect to an IP address it has already identified as faulty.|
|Maximum Reconnects||3||An edge server will contact your origin server this number of times. If your origin is associated with several IP addresses, this value overrides the value of Retry Count.|
Script Management only affects referenced scripts, which are external resources that require a separate request. You can't apply Script Management to
script elements that are embedded in the pages of your website or app.
Before you can set up and use Script Management, you need to do some things:
You need mPulse. Script-use data is collected in "beacons" and sent to Akamai's mPulse service. Script management needs to communicate with mPulse to get this data. The mPulse RUM sub-rule is included in your Ion property by default.
Supported browsers. If you're looking to apply a specific action after Script Management analyzes script usage data, Akamai needs to install the Script Management service worker on a requesting browser. This service worker is currently supported with the following browsers:
- Chrome. This includes both desktop and mobile versions.
- Firefox. This includes both desktop and mobile versions.
- Safari. Only the desktop version is supported.
Set up the Script management sub-rule by following these steps:
This rule's Criteria is set to match all requests. We recommend that you leave it set this way.
Set Enable to On and select the appropriate Mode for Script Management's service worker:
Analysis and action. Select this mode to see the analysis of your scripts and then either block or defer any scripts based on the analysis. This mode also installs the service worker on a client browser.
Analysis only. Select this if you want to see the analysis of your scripts, but don't need to block or defer any scripts based on the analysis. Use this mode if you only want to view information on your scripts. This mode doesn't install the service worker on a client browser.
Once you activate your Ion property on the production network to go live, give mPulse some time to gather the necessary data on script usage.
You can use the Script Management dashboard to review useful information about the scripts on your site.
Updated 7 months ago