Minimum Requirements and Supported Platforms

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

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:

Note: When embedding iFrames, Sisense supports Safari 10 and higher.

Microsoft Edge is not currently supported.

The Sisense Web Application also works in mobile phone and tablet browsers that support HTML5. Click here to learn more about mobile compatibility.

Supported Operating Systems

For Windows

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

If you are installing Sisense in Windows Server 2019, see Disabling Windows Defender Real-Time Protection.

Note: While Sisense supports different versions of Windows, it is highly recommended that your production environments use Windows Server 2008 R2 and later.

For Linux

Sisense Linux Cloud- is certified to run on the following operating systems:

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:

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 ElastiCubes, 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.

For optimal performance, Sisense highly recommends that your servers have a processor that supports AVX (Advanced Vector Extensions), which is leveraged by Sisense for improved query performance and user concurrency.

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.

  Small-Scale Mid-Scale Large-Scale

Users

50

200

500

Active (Concurrent) 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.

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, whether it is the row-count per table, the number of tables, or a combination of the two, has a major impact on the memory consumption of a Sisense server during a build and query. 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 we recommend to set 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.