Windows Minimum Requirements

This page includes prerequisites and supported platforms that are required when working with Sisense on Windows.

Below you can find links to the section relevant for you:

Supported Web Browsers

The Sisense Web Application runs in the following HTML5 supported browsers:

• Edge (only Chromium-based, version 79 and later)
• Google Chrome
• Firefox
• Safari version 7 and later

The Sisense Web Application also works in mobile phone and tablet browsers that support HTML5. Click Viewing Dashboards on Mobile Devices to learn more about mobile compatibility.

Windows Operating System Requirements

The ElastiCube Server and ElastiCube Manager can be installed on the following 64-bit operating systems:

• Windows 7, Windows 10 (Note that Windows 11 is not supported)
• Windows Server 2008 R2 through Windows Server 2022

If you are installing Sisense in Windows Server 2019 or newer (e.g., 2022), see Disabling Windows Defender Real-Time Protection.

Hardware Requirements

Sisense scales up to billions of records with typical query response times in under a few seconds.

This section suggests hardware requirements for various performance capacities of the ElastiCube Server when connecting to data sources with Live connections or importing data into an ElastiCube. Actual capacity requirements are provided after consultation with Sisense. Extreme scenarios may require additional resources.

Note the following:

• For Sisense Viewers, only an HTML5 compliant web browser is required.
• For cloud deployments, regardless if you are using AWS/Azure/Rackspace/etc., you must choose a machine that meets the recommended hardware configuration described in the table below.

System Requirements

Live Models
When connecting to a Sisense Live data source, Sisense recommends a minimum of 16GB memory with 8 cores. For use cases with 100s of users concurrently connecting to your data source, contact your CSM for more information about Sisense's minimum requirements.

You can create up to 400 Live models on one Sisense instance.

ElastiCube Models
The table below describes the minimum requirements for your production Sisense Server responsible for managing ElastiCubes. It is important to note that it is possible to exceed the large-scale machine deployment size given in the table below with machines that have more memory and cores.

Deployment Size	Small Scale	Medium Scale	Large Scale
CPU	8 Logical Cores	16 Logical Cores	32 Logical Cores
System Memory	16GB	64GB - 128GB	256GB - 512GB
Sisense Installation Directory	~20GB	~20GB	~20GB
ElastiCube Data Directory	~50GB	~200GB	~800GB
Application Logs Directory	3G	5G	5G

Sisense Recommendations

Sisense recommends that your Sisense server meets or exceeds the recommendations listed above. The actual requirements of your Sisense server may vary depending on the number of concurrent users, builds running in parallel, number of ElastiCubes hosted on a server, the complexity of the ElastiCube s, and additional factors specific to your server, for example, non-Sisense applications running on the same server. When deploying Sisense on a single server, it is recommended to plan in advance for possible additions (for example free slots for RAM or hard disk) on physical machines or virtual scale up (for example adding computing resources) on virtual machines. It is also highly recommended to use a dedicated machine (physical or virtual) and refrain from using the Sisense server for other services.

The following table lists sizing recommendations for a Sisense installation deployed on a single Windows server, based on average use cases and hardware demands. The specific recommendations depend on the specific query load patterns and use cases.

If you find that you are running in the upper limits of the large-scale recommendations, consider splitting the server functionality into multiple nodes or a Linux architecture deployment. For more information, see Sisense Architecture.

	Small-Scale	Mid-Scale	Large-Scale
Users	200	800	2000
Concurrently Active Users	10	40	100
ElastiCubes	5	20	40
Number of tables per ElastiCube	20	50	70
Parallel ElasticCubes Build Processes	2	4	4
Live Models	100	400	400
Max Number of rows per Table	20M	300M	1B
Number of Custom Tables in an ElastiCube	5	10	25
Number of Custom Columns in an ElastiCube	10	20	50
Number of Different Sources (Connectors) per ElastiCube	3	5	10

Expected Usage for a Single Machine

Sisense customers vary in terms of production deployments that represent different needs. The following is typical usage for a single Windows machine, which can serve as a good indication of the typical single machine load. Such a machine will be mid-scale or large-scale, depending on the number of concurrent users and the load of the build process. If your expected usage is approaching the maximum values, consider splitting the server functionality into multiple nodes or a Linux architecture deployment. For more information, see Sisense Architecture.

Note that maximum values represent the maximum load tested in different scenarios, however, there is no hard limit that will prevent a Sisense system on a single machine from crossing these values*(1).

Category	Typical Deployment	Maximum
Number of ElastiCubes	5-10	40
Number of Tables per ElastiCube	5-15	150
Data Size (Total ElastiCubes)	20-30 GB	1000 GB
Concurrent Users	10	100

*(1) Appropriate license may be required to reach a certain load. For example, the number of maximum rows in a table can be limited by the purchased Sisense license regardless of the system capabilities.

Considerations

The following are some considerations to take into account when deploying Sisense:

CPU Considerations

Each Sisense widget produces at least one query to the ElastiCube or Live source when viewed. As a dashboard is a collection of widgets, viewing a dashboard produces multiple queries, which in turn raises CPU usage. Concurrent queries affect CPU utilization and are independently spread between different CPUs. While this concurrency is a core activity of Sisense, it is important to consider the correlation between the number of concurrent users/active dashboards and increasing CPU usage. It is especially important to track CPU usage when increasing the number of concurrent users or active dashboards. Lack of CPU resources will cause dashboards to load slowly. When CPU usage consistently increases above 80%, it is recommended to add CPU resources.

In addition, custom tables and custom columns will increase the CPU load at the end of a build process according to the complexity of the functions used by those custom tables and columns. In this case, adding more CPU resources will help to decrease the total build time.

Building an ElastiCube can consume a lot of CPU resources. However, CPU consumption is not linear while performing parallel builds, and it is possible to run several builds at the same time. A single Windows server supports up to four parallel builds. Sisense is typically capable of running four parallel builds while consuming only half of the CPU resources compared to the same builds run separately. It is possible to run build processes and view dashboards at the same time, however, as both are CPU consumers, Sisense recommends that you schedule builds to run at times of low dashboard viewing, like during the night.

RAM Considerations

Building ElastiCubes and viewing dashboards both require memory. While it is possible to view dashboards at the same time as running build processes, the RAM resources required for those activities will be aggregated. When using a single-server Sisense deployment, it is important to take both into account and plan RAM usage accordingly. To prevent out-of-memory build failures, it is advisable to run the build process at low-usage schedules or separate the build and the query nodes to different machines.

The size of your ElastiCube model has a major impact on the memory consumption of a Sisense server during a build and query. This is equally true when considering the row-count per table, the number of tables, or a combination of the two in an ElastiCube model. Memory consumption often peaks when building a custom table. Columns with unique data types, like strings, which are indexed during the build process, are cached in memory, for example, large string columns with many unique values may increase memory consumption.

There is a correlation between the data size on the disk and the required RAM. Sisense InChip© technology will load large portions of the ElastiCube to the memory hence the number of active cubes and the cubes total size is a very important sizing factor for the RAM size.

Disk Space Considerations

The Sisense installation file is typically around 1.5GB in size. Once Sisense is installed, Sisense uses about 20GB of space. In general, when determining how much disk space to reserve for Sisense, keep in mind the size of the data to be imported into your ElastiCube models. You should keep additional space to support your ElastiCube models, as these are duplicated during the build process. The duplicate copy is not removed at the end of the build process but serves as the basis of the next build.

An additional important consideration is the custom columns and tables, which are materialized on the disk during the build process. Hence it is important to add the required disk space for these data to the total estimated data size.

In addition to the imported data size, the ElastiCube also holds metadata like indexes. Actual cube size on the disk will be extended due to this internal metadata, hence it is good practice to plan for 20% overhead on top of the imported data and custom tables.

Typically the ElastiCube data is stored compressed. However, it is good practice to plan for the required disk size without taking the compression into account, since in different scenarios one may choose to disable the data compression for build and query performance improvements.

If you need to store your ElastiCube models in another location other than the default C drive, see Change the Location of ElastiCube Data Folders.

For staging or demo environments, consider using high-speed hard disks (e.g. 7200RPM+) for the home directory and backups, while for production environments, use Solid State Disks (SSD) utilizing NVMe to ensure high I/O performance.

Page File Considerations

Windows OS page size settings have an effect on performance and should be considered. The default recommendation is to set the page size to 150% of the RAM size. When possible, and disk space is not an issue, Sisense recommends setting the page size to 300% of the RAM size. By extending the page size one can use storage resources to avoid out-of-memory errors but need to consider that when paging is used the system will respond slower. In a large system with 128GB RAM or more, it is not always feasible to set a huge amount of page file on the server as it requires very large disk space. For the server's with a large amount of RAM, you might want to limit the page file size equal to 128 GB at least.

In addition, it is recommended to split page files on two different drives (preferably on two different physical/virtual disks) on the server for better disk I/O performance.

Data Sources Considerations

Connectors affect memory consumption linearly. The usage of each connector has a predefined (and configurable) memory allocation, hence increasing the number of different connectors which are used during the build process increases the memory consumption.

.r.