Sizing Guidelines

To maximize the operational efficiency of Composer, you need to take into account several factors to appropriately size the Composer Server in your operating environment:

  • Size of the data. Composer queries push the work for the query down to your data stores as much as possible. So scale your data store storage to support most Composer queries.

  • Number of concurrent users during peak access times. If you expect more than 200 concurrent users to run Composer at peak times, your sizing requirements will be greater.

  • Number of data sources, dashboards, and visuals in the system. In general, the more sources, dashboards, and visuals you have, the larger your sizing requirements. (For example, 1000 users of a couple of data sources and dashboards will require lower sizing requirements than 100 users of thousands of data sources and dashboards.)

  • High availability (HA). If your Composer environment is an HA environment, sizing requirements may double if each Composer microservice is running on multiple instances.

To better understand how to size your server for optimum performance, review the following information. If you have unique sizing needs for your environment, contact Composer Technical Support for more information.

See also System Requirements for information about Composer system requirements.

Sizing Profile

Profile Description

Demo, Proof of Concept (POC) The most basic profile, supporting 1-2 concurrent users.
10s of Users For the smaller organization that will have less than 100 users at any given time.
100s to 1000s of Users

For the mid-size to large organizations that will have 100 or more users at any given time.

Contact Composer Technical Support to get help in setting up Composer in your operating environment in the best configuration possible.

Server Sizing

Sizing the server requires using a performance profile based on the expected number of concurrent users. Also keep in mind the size and number of data sources being accessed by Composer impacts the sizing profile. Scale-out and load balancing may also be needed, depending on your organization’s operating environment.

Adjust your hardware to account for both an increasing number of users and size of the data source:

  • CPU: number of cores
  • Memory allocated to Composer
  • Disk space that may be used by Composer

The following table reviews the recommended sizing guidelines for your server. Keep in mind that the specifications provided are suggested starting points and reflect only the minimum estimates. Sizing Composer for performance is impacted by many other factors outside of the ones mentioned here, such as where Composer resides, the types of data sources you are using, interactions between applications and data sources, and a variety of other factors.

Concurrent users represent only a portion of the total number of available users in an organization who may access the Composer server at the same time. In general, Composer estimates that 20% of the total user base will be logged onto Composer at any given time. So if an organization has 1000 total users that have access rights to Composer, we estimate that 200 users may be logged concurrently.

A single Composer server has been tested for up to 100 concurrent users at any given time. When testing user concurrency, factors including the cardinality of the data sources, loading, sharpening, and visualizing results in dashboards were considered.

Sizing Profile (For Concurrency) Size of the Data Source CPU: # of Cores (Minimum) Memory allocation JVM Memory allocation Disk space (Minimum) Supported # of concurrent users (Per server) Assumptions

Demo, POC, 1-2 users

Megabytes (MBs) of data

4

16 GB

8 GB

(default)

250 GB

1-2

Metadata store is embedded (on the same server as Composer)

10s of concurrent users

Gigabytes (GBs) of data

16

64 GB

20 GB*

500 GB

<100 Metadata store is embedded (on the same server as Composer)

100s to 1000s of concurrent users

Terabytes (TBs) to Petabytes (PBs) of data

Contact Composer Technical Support 100+ Contact Composer Technical Support

By default, the JVM memory setting is set to use a max of 8 GB. For 10s of concurrent users, the recommended allocation is 20 GB. For instructions to increase the JVM memory, read Configuring Memory Settings.

Composer Microservice Memory Allocation

Each microservice within Composer has a default sizing configuration. To better understand how much memory each Composer microservice uses so that you can judge your performance needs, review the following table. You can also use Composer's memory allocation script to calibrate your environment. Doing so calculates the memory allocation for each microservice based on the total memory available on your server or a specified amount for memory allotment. For more information, see Composer's memory adjuster on github.

Service Name What it does Required to run? Default memory
zoomdata Entry point and provides front-end configurations Yes JVM: 2GB
zoomdata-query-engine Holds all functionality related to visual query processing Yes JVM: 6GB
zoomdata-screenshot-service Provides ability to view snapshots of saved dashboards on Composer Home page No JVM: 256MB
zoomdata-edc-<connector>* Connects to the specific data store Yes JVM: 250MB per connector
zoomdata-data-writer-postgresql A receiver for messages to write data or perform operations on collections No Varies

* EDC memory allocation varies when the connector is not in use. Memory varies based on the number of concurrent requests and query results.