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 | 32 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.
Do not allocate more than 85% of your total system memory to all microservices.
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.
Comments
0 comments
Please sign in to leave a comment.