Applies to: 
Kyvos Enterprise Kyvos Cloud (SaaS on AWS) Kyvos AWS Marketplace
Kyvos Azure Marketplace Kyvos GCP Marketplace Kyvos Single Node Installation (Kyvos SNI)
To handle high concurrency requirements, update the configurations for the Kyvos environment, as explained in this section.
It is recommended to configure your environment before starting concurrency testing.
To set up the environment for high concurrency:
Enable Kyvos Services High Availability from the Kyvos Manager
Set the BI Server heap memory to 48 GB
At least two BI Servers must be available
Recommended properties for concurrency configuration:
Kyvos component | Property name | Description / Value |
Semantic model | Kyvos.query.resultcache.strategy | This property specifies BI Server's strategy for caching metadata and user query results. You can set this property from the Semantic model Advance properties screen. Read more. |
Kyvos.query.cuboidcache.strategy | This property specifies the cuboid cache level. This is an off-heap memory-based cache on the Query Engines. Enabling this cache helps improve the performance of queries. You can set this property from the Semantic model Advance properties screen. Read more. | |
Query Engine | CUBOID_PURGE_FREQUENCY | This property specifies the file system purge frequency. That is, the interval after which the purge thread execution for cuboids is repeated (specified in minutes). Syntax: CUBOID_PURGE_FREQUENCY= [>0] (int) Default: 30 |
BLOCK_CACHE_LIFETIME | This property defines the lifetime of the block cache to ensure the timely removal of cuboid blocks from the global cache. Default: 24*60 minutes (1 day) = 1440 | |
QUERY_ENGINE_THRIFT_WORKER_THREAD | This property defines the number of worker threads from the BI Server to the Query Engine. Each query occupies one thread and in case of a multi fact query, each fact occupies one thread. This means, for a multi-fact query having five facts, a single query will consume five worker threads. For high concurrency requirements, the value of this property should be equal to the number of expected concurrent users. Default: 10 This means ten users can query in parallel for a single fact semantic model. All other requests will be processed in a queue. | |
PARALLEL_READS_PER_QUERY | This property defines the number of cuboids that each Query Engine reads in parallel for a given query. The default value for this property is 10, which means each Query Engine can serve up to 10 cuboids in parallel per query. You may want to reduce this number if a less number of cuboids are being queried per Query Engine per request, which will increase the locally available cache capacity for Query Engines. Change the value of this property according to the number of users, memory per Query Engine, and the number of cuboids being queried per request per Query Engine. | |
BI Server | OLAP_EXEC_THREADS | This property specifies the query execution threads of the BI Server. These threads handle query execution requests. The value of this property defines the number of query execution requests that must be served simultaneously. The default value of this property is 5. In the case of higher concurrency, the value should be set 20% more than the number of concurrent users expected. For example, for 100 concurrent users, the value of this property should be set as 120. |
CUBOID_PURGE_FREQUENCY | This property specifies the file system purge frequency. That is, the interval after which the purge thread execution for cuboids is repeated (specified in minutes). Syntax: CUBOID_PURGE_FREQUENCY= [>0] (int) Default: 120 |
Tips
You can configure properties for the Query Engines and BI Servers in the queryengine.properties and the olapengine.properties respectively from the Properties page on the Kyvos Manager.
Steps for executing warm queries
For Kyvos, warm queries are the queries served from the BI Server. For these queries, the Result Cache is On.
Steps to execute warm queries:
Restart the AppMaster from Kyvos Manager.
Set the following properties at the semantic model level.
Kyvos.query.resultcache.strategy=ALL
Kyvos.query.cuboidcache.strategy=VERY HIGH
Execute queries from Beeline to populate the BI Server cache.
Steps for executing cold queries
For Kyvos, cold queries are the queries served from the Query Engines. For these queries, the Result Cache is Off, and the cuboid cache is enabled.
Steps to execute cold queries:
Set the following properties at the semantic model level.
Kyvos.query.resultcache.strategy=NONE
Kyvos.query.cuboidcache.strategy=VERY HIGH
Set the following properties in the Kyvos Manager based on the number of users. See the table below for suggested property values according to the number of concurrent users.
QUERY_ENGINE_THRIFT_WORKER_THREADS
PARALLEL_READS_PER_QUERY
CORES PER QUERY ENGINE
Set the BLOCK_CACHE_LIFETIME=0 in Kyvos Manager so that the cache remains always.
Restart the AppMaster
Execute all queries from the beeline to bring cuboids in the cache every time the AppMaster is restarted.
Number of concurrent users | 10 | 20 | 50 | 100 |
QUERY_ENGINE_THRIFT_WORKER_THREAD | 10 | 20 | 50 | 100 |
PARALLEL_READS_PER_QUERY | 15 | 10 | 5 | 3 |
CORES PER QUERY ENGINE | 10 | 12 | 24 | 36 |
Note
It is recommended to enable the result cache for high concurrency environment. When local replication is disabled, or the off-heap memory is not enough to hold the semantic model in memory, the cuboids are read from the HDFS, which is slow and depends on factors like cluster load. At high concurrency, if the queries are served through HDFS reading, then the I/O time will be high, and the query response time will increase.