If your Spotfire Web Player consistently experiences a non-equal distribution of resources, then review the configuration to determine how to better distribute resource pools and routing using these concepts and rules.

A status of Strained for a Spotfire Web Player is not necessarily a cause for concern; it just indicates that the Spotfire Web Player is busy and not overloaded. You can change the threshold that pushes the Spotfire Web Player into a Strained status, depending on the specifics of your hardware. For example, a Spotfire Web Player with 512GB of RAM might always show Strained status, with the default threshold of 75% for RAM, even though that means that there is 128GB of RAM available. Changing the threshold can be more reasonable, in some cases.

• Lowering these thresholds can result in Spotfire Server routing analyses across more instances but may require more total RAM usage as a given analysis will be loaded multiple times.
• Raising these thresholds means the Spotfire Web Player now handles more users and load, and makes better use of its resources.
  Warning: Setting the thresholds too high can slow response time.

By default, Spotfire Server does not open the same analysis on a second Spotfire Web Player instance if Spotfire Server determines that the first Spotfire Web Player is Available. This can result in requests cascading across all instances in a resource pool, so that the second instance is used only when the first instance is Strained, and the third instance is used only when the first and second instances are both Strained. You can change this behavior by changing the configuration, as follows.

• Lower the thresholds for the StrainedLimit configurations. See Spotfire.Dxp.Worker.Host.exe.config file for more information.
• Create a routing rule to preload the analysis on two or more Spotfire Web Player instances. If an analysis is on multiple Spotfire Web Player instances, then new requests are routed to those instances, based on status (Available before Strained), and then least number of sessions.

The general routing algorithm is as follows.

• A user with an active analysis session always goes to the same instance.
• Requests matching a routing rule are routed to the specified resource pool, in order of rule priority.
• All other requests are routed to the resource pool(s) defined in the Default Routing Rule.
• If an analysis is assigned to a rule, then that rule takes precedence; therefore, if a rule assigns an analysis to a given resource pool, and all instances in that resource pool are down or Exhausted, then the analysis does not load.

When all else is equal, and multiple instances could be selected, the router attempts "smart routing", as shown in the following diagram.

Note: * Additional options exist for instances in the Exhausted state, whether a request is already loaded in Scheduled Updates, and how new requests are handled.

See Routing rules for more information.