Sizing considerations for Spotfire Web Player

The Spotfire Web Player is a service connected to the Spotfire Server to provide the ability to run or create Spotfire analyses in a web browser. The Web Player service typically runs on a separate bare metal server, virtual machine or container.

The Spotfire Web Player service handles user interaction with analytic applications or dashboards. It has an in-memory engine that serves 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 latency and throughput, temp disk space, or database processing capacity.

General insights

The Web Player uses two types of memory: Data engine memory and .NET memory, which is used for logic and for visualizations, respectively. You can monitor both types using performance counters that the process logs by default.
By default, if the amount of available data engine memory is below 15%, Spotfire pages out the data engine memory. This behavior is by design because there might be data that is actually not needed in memory all the time.
For better resource allocation and data loading performance, the default routing aims for a high degree of data sharing between users accessing the same data sources or analyses, provided that they are routed to the same Web Player service. You can modify the routing behavior for other scenarios. See Tuning the load distribution between Spotfire Web Player instances for more information.
A Web Player instance resides on one Web Player service only. There is no data sharing between services, so a huge analysis cannot be divided between them. For example, if one analysis needs 50 GB of RAM, at least one Web Player service that is large enough is needed, and you should use routing rules to ensure that the huge analysis is always routed to that service.
It is recommended to have redundancy for all parts of the system to avoid single points of failure.

Running under Kubernetes

Because the 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. See the Kubernetes documentation for more information.
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 analysis authors to design smaller analyses instead of huge, monolithic analyses (which might have previously been convenient).

Minimum hardware requirements

The Web Player requires at least two cores, but six or more is recommended. More cores are needed for complex, data rich applications, and to handle more users. You can use multiple Web Player nodes for high availability. The actual number of simultaneous users that the system will support with a given number of cores depends on the following factors:

The volume of data per report and the number of reports.
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 plot visualizations, or statistical engines such as Python, R, or TERR).
Compressibility or “entropy” of the data.
Whether users can share data sets, or whether row-level security is required

Sizing the Web Player services

Hardware sizing must 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 the needs of a single user, do the following.

Test the intended analyses in a scenario that is as realistic as possible using the installed 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.