Origin Health Detection

This behavior monitors the health of your origin server by tracking unsuccessful attempts to contact it. Use this behavior to keep end users from having to wait several seconds before a forwarded request times out, or to reduce requests to the origin server when it is unavailable. Be advised that misusing this behavior can increase hits to the origin exponentially.

How it works

When client requests are forwarded to the origin, the edge server tracks the number of attempts to connect to each IP address. It cycles through IP addresses in least-recently-tested order to avoid hitting the same one twice in a row. If the number of consecutive unsuccessful tests reaches a threshold you specify, the behavior identifies the address as faulty and stops sending requests. The edge server returns an error message to the end user or else triggers any Site Failover behavior you specify.

πŸ“˜

In order for an IP to be marked as faulty, it will need to fail the maximum number of attempts consecutively.

Features and options

Field

What it does

Retry Count

The number of consecutive connection failures that mark an IP address as faulty.

Retry Interval

Specifies the amount of time the edge server will wait before trying to reconnect to an IP address it has already identified as faulty.

Maximum Reconnects

Specifies the maximum number of times the edge server will contact your origin server. If your origin is associated with several IP addresses, it effectively overrides the value of Retry Count.

❗️

Edge servers will try to connect to a forward server (the origin or possibly another edge server in cases of SureRoute or Tiered Distribution) with a formula of max-reconnects + 1 (the initial connection attempt). When using Origin Health Detection with SureRoute or Tiered Distribution, the edge server may forward max-reconnects +1 to a parent server who will then do the same with the origin. That initial edge server may try connecting with a different parent server if the previous parent returns null. The result is that for every one request sent forward to a parent server, each parent server will potentially apply max-reconnects + 1 to your origin.


Did this page help you?