Understanding routing

When a request is made to open a specific analysis file, the routing mechanism goes through the configured routing rules in priority order. The applicable rule could be a routing rule, a scheduled update (SU) rule or the default routing rule, resulting in one or more service instances to choose between. This topic describes how the routing is done on the server.

From the service instances that are available for selection, the routing mechanism considers the following, in order:

The group of instances with the best available health status. Instances of the status 'Available' are always chosen before instances with a lower health status. ¹
If the analysis is already loaded on one or more of these instances, the router will choose one of them.
The instance with the fewest number of user sessions is selected. If there are more than one matching instance with the same number of user sessions, then one of them is used.

Health status

There are three health status codes for Web Player instances, used to better route traffic among the instances: Available (or OK), Strained, and Exhausted.

The health status codes are calculated from the resource status (that is, the CPU, memory usage and others) on the node that is running the service instance. For more information on health status, see Web Player and Automation Services resource usage.

The health status for the existing instances can be monitored on the Monitoring and diagnostics pages in the Spotfire web administration pages.

Note: A service instance can be busy frequently, with a high CPU or memory usage, causing it to remain in the Strained state for long periods of time. For more information about managing the state of service instances, see Tuning the load distribution between Spotfire Web Player instances.

Decision flow

The diagram below shows the routing mechanism decision flow:

Routing examples

Scenarios and routing behavior:

An analysis is scheduled to be updated using scheduled updates (SU) and it is already loaded on two or more service instances:
- The user will be routed to the service instance with the best health status of those where the analysis is already loaded. If there are several instances with the best health status, the user is routed to the instance with the lowest number of sessions.
An analysis is scheduled using SU and it is already loaded on one service instance:
- The user will be routed to the service instance that is in use.
An analysis is not scheduled using SU but it is already opened (in use) by another user:
- If there are other service instances with better health status, the user will be routed to the one of them with the lowest number of sessions.²
- Otherwise, the user is routed to the instance where it is already open.³
An analysis is not scheduled using SU and not in use by another user:
- The user is routed to the one of instances with the best health status which has the lowest number of sessions.
An analysis is not scheduled using SU but there is an applicable routing rule:
- The user is routed to the instance pointed out by the rule, with the best health status.

Example 1: Analysis "A"

Routing when opening analysis "A" (assuming that no rules affect the routing):


Step	Instances	Notes
1. View the instances and locate the ones with the best health status (available-strained-exhausted).		You can configure the CPU/memory/other levels at which an instance is considered available-strained-exhausted. For the routing, the health status is considered only at the label level: available-strained-exhausted (not CPU/mem). The instances with the "best" health status are the "available" instances. If there are no "available" instances, then all "strained" instances are considered. If there are no "available" nor "strained" instances, then the "best" health status is "exhausted".
2. Select instances where the analysis "A" is loaded.		A loaded analysis can use a different amount of resources based on the number of users currently running that analysis, and their activity.
3. Select the instance with the minimum total number of user sessions (including all analyses).		Select the instance with the lowest total number of user sessions. If there are more than one matching instance with the same number of user sessions, then select one (any) of them. A loaded analysis can use a different amount of resources based on the number of users currently running that analysis, and their activity.

Example 2: Analysis "C"

Routing when opening analysis "C" (assuming that no rules affect the routing):


Step	Instances	Notes
1. View the instances and locate the ones with the best health status (available-strained-exhausted).		You can configure the CPU/memory/other levels at which an instance is considered available-strained-exhausted. For the routing, the health status is considered only at the label level: available-strained-exhausted (not CPU/mem). The instances with the "best" health status are the "available" instances. If there are no "available" instances, then all "strained" instances are considered. If there are no "available" nor "strained" instances, then the "best" health status is "exhausted".
2. Select instances where the analysis "C" loaded if there are any, otherwise take the result from step 1.		A loaded analysis can use a different amount of resources based on the number of users currently running that analysis, and their activity.
3. Select instance with the minimum total number of user sessions (including all analyses).		Select the instance with the fewest total number of user sessions. If there are more than one matching instance with the same number of user sessions, then select one (any) of them. A loaded analysis can use a different amount of resources based on the number of users currently running that analysis, and their activity.

¹ Note that if the analysis is in an active scheduled updates rule, only those service instances where the analysis is loaded will be considered.

² In this case, the user must wait for the analysis to load, but because the service instance where the analysis is already loaded is strained, it is better to have it loaded on another instance.

³ If the analysis has embedded data only, the users will share both document and data and the response will be very fast because there is no need to load the analysis again.