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.

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.

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.

Do not allocate more than 85% of your total system memory to all microservices.

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