Sizing considerations for Spotfire Web Player

Spotfire® Web Player is a service connected to the Spotfire® Server to serve content to application users (Business Author and Consumer). It typically runs on a separate computer or computers.

Spotfire Web Player service handles user interaction with analytic applications or dashboards. It has an in-memory engine that services zero-footprint web clients. There is not much of a difference whether the Web Player is running on a physical computer with Windows or inside a Linux container under Kubernetes. The Web Player is designed for performance and scalability. It should run alone on the server (or in a container), and the assumption is that when the user load is high, it consumes more or less all available resources, so you should not worry about high resource usage. The most critical resources are often Web Player memory and CPU, but certain use cases can lead to other scarce resources, like network, temp disk or database processing.

General insights

The Web Player uses two types of memory: Data engine memory and .NET memory, which is used for logic and visualizations. You can monitor both types using performance counters that the process logs by default.
By default, if the amount of available memory is below 15%, Spotfire pages out data engine memory. This behavior by design because there may be data that is actually not needed in memory all the time.
There is a very high degree of data sharing between users of the same or similar data, but only if they are routed to the same Web Player service.
An analysis instance resides on one Web Player service only; there is no data sharing between services, so a huge analysis cannot be divided between them. If one analysis needs 50 GB of RAM, at least one Web Player service that is large enough is needed, and routing rules should ensure that the huge analysis is always routed to that service.
Make sure to have redundancy for all parts of the system to avoid single points of failure.

Running under Kubernetes

Because Spotfire Web Player process contains a huge data state that can take hours to build, make sure that it runs in a container with Quality of Service (QoS) Class Guaranteed to reduce the risk of being recycled by Kubernetes.
A killed container can result in the end user waiting for hours while the state is recreated in a new container. Consider using scheduled updates to pre-load critical analyses on at least two services.
Because it is common to use smaller containers than traditional servers, consider advising analysts to design smaller analyses instead of huge, monolithic analyses (which might have previously been more convenient before).

Minimum hardware requirements

Spotfire Consumer should have a minimum 2 processors. 6 is recommended. More processors are needed for complex data rich applications and to handle more users. You can split the processors across multiple web player nodes for high availability. The actual number of simultaneous users that the system will support with a given number of processors depends on the following factors.

The volume of data per report and the number of reports.
Compressibility or “entropy” of the data.
The number of concurrent users.
Complexity of calculations (more CPU capacity is required for non-linear complexity calculations, such as median, percentile, and so on).
The number and complexity of visualizations.
Requirements for advanced statistics (such as box plots or statistical engines such as R, TERR, Matlab, or SAS).
Whether users can share data sets, or whether row-level security is required

Sizing the Web Player Services

Hardware sizing needs to accommodate the number of users and the complexity of the data; however, it can be very difficult to estimate hardware needs, even given some basic facts about data size, number of users, and so on. Start with a rough estimate based on the memory needs for one single user. To benchmark a single user need, do the following.

Test the intended analyses in a scenario that is as realistic as possible using the desktop client and measure its memory and CPU usage.
Depending on the number of different analyses and the number of users for each of them, assume data sharing of about 90% between users of the same analysis, and then sum up to get a rough estimate of the total need of memory and CPUs.
Determine the host sizes to ensure enough resources for all types of analyses to fit in.
Set up and test with a realistic number of users. Test with scheduled updates, resource pools, and routing rules to get data sharing and reasonable use of each Web Player service.
Scale up and scale out as needed.