Basic settings

Full list of configuration parameters

Configuration File	Variables
./cfg/smc.settings.cfg	apiserver_advertise_address: address of the kube-apiserver. In most cases this is the machine's internal IP address. external_ip_address: address for the ingress-controller. Here you need to specify the machine's external IP address.
./cfg/license-server.settings.cfg	license_key: this key is usually sent in the accompanying email to the distribution kit. To get the key, contact your sales manager. This key is not required for the trial period. license_server_address: IP address of the machine, on which the license server will be installed
./cfg/platform.secrets.json	license-secret : here you need to set a license key and address of the license server instead of license_server_address. docker-registry : values to specify if external docker-registry is used rabbit-secret: user name and password to get access to a message broker, used for internal interaction of OMNI Platform services. Set an arbitrary name that consists of Latin letters without spaces and a password that consists of Latin letters and numbers without spaces. postgres-root-credentials: user name and password for root user in the database platform-service-key: secret key required for internal communication between OMNI Platform services platform-user-secret: user credentials (email address and password) used for access to OMNI Platform. Users will be created automatically on the first deployment. The specified email address must include numbers, Latin letters and symbols. platform-email-secret: SMTP server settings. To disable sending emails, leave these fields blank. minio-credentials: username and password for root user in object storage
./cfg/platform.values.yaml	backend.query_limit: this value limits the number of returned elements in API requests to get system objects. Increasing this limit is not recommended, as API request runtime may increase several times. Also, please note that increasing the limits will lead to the system degradation. backend.index_update_period: this value in seconds describing the amount of time the added profile will appear in the search index. The default value is 60 seconds. To speed up the index updating, decrease the parameter value. backend.enable_profile_autogeneration: auto-generation of profiles for incoming activities from the agent. Please note that enabling this option will increase the consumption of license resources (database size). To enable this function, set the value to 1. processing.use_cuda: responsible for use graphics card in processing service. 0 – disabled, 1 – enabled. ingress.rules.gateway.host: domain name or IP address used in ingress to route requests to Kubernetes services postgres.enable: disable if using your own database server. You need to change the values for postgres-root-credentials in the ./cfg/platform.secrets.json file and the values for postgres.host and postgres.port in the current file. minio.enable: enabling means that object storage will be used to store images. If you disable this option, postgres will be used to store images. Note: If after the first deployment a certain number of images have already been collected, you should not disable this option, since then you won't be able to obtain this data. This option must be disabled for AWS deployment. minio.buckets_prefix: specifies the prefix for all buckets that will be used by the module in MinIO in the format <prefix>.<bucket name>. If a prefix is not required, leave the field empty. Note: If you need to preserve data in MinIO from the previous version, also leave the field empty. matcher.shard_n: interface parameter, regulates the number of simultaneous calls to matcher-serivice. Must be equal to the shard.quantity parameter in the matcher.values.yaml file event_service.pool_size: the maximum number of active and inactive connections in the pool that a single worker can use. event_service.max_overflow: the maximum number of temporary connections that can be opened beyond the value specified in the event_service.pool_size parameter. For more details, see a Database connections section. event_service.pool_recycle: the time in seconds after which connections in the pool should be reopened. event_service.pool_pre_ping: a parameter that enables or disables the database connection check before sending requests. Note: This parameter controls the service-side connection check; the database-side handling is configured separately. event_service.ws_timeout: the time in seconds after which a WebSocket connection will be closed during interruptions. event_service.bucket_names: the names of the buckets that the event service will use. Note: Do not change the bucket names if you need to preserve data from the previous version.
./cfg/matcher.values.yaml	shard.quantity: the number of shards to be created; increasing the parameter allows you to speed up searches on large data shard.search_threads_n: the number of threads used to perform the search
./cfg/platform-ui.values.yaml	ingress.host: domain name, used in ingress to route requests to Kubernetes services. The value must match the value of ingress.rules.gateway.host in the ./cfg/platform.values.yaml file.

Scalability

When the load increases, the following services can be scaled in manual mode to stabilize OMNI Platform operation:

• image-api-face-detector-liveness-estimator-dep
• image-api-quality-assessment-estimator
• image-api-age-estimator
• image-api-gender-estimator
• image-api-mask-estimator
• image-api-emotion-estimator
• image-api-face-detector-template-extractor-dep

To scale the service, run the command below:

kubectl scale deployment <SERVICE_NAME> --replicas <COUNT>

where SERVICE_NAME is a service name (for example, gateway-dep), and COUNT is a number of service instances.

To keep the load of A requests/sec for image processing, on a server with a physical number of CPU cores equal to B, you should set the value of replicas of each of the specified services according to the formula min(A, B).

To save the scaling settings open the ./cfg/platform.values.yaml and ./cfg/image-api.values.yaml files, find the replicas field in the service module, and set new values.

For the next installations of the platform and image-api, services will be automatically scaled to the specified values.

tip

When the number of image search requests increases, you'll need to increase the number of replicas of the image-api-face-detector-template-extractor-dep service. You can also increase the number of threads that are used to extract the biometric template.

When the number of requests for detection, creating profiles, and creating samples increases, you'll need to increase the number of service replicas:

• image-api-face-detector-liveness-estimator-dep
• image-api-age-estimator
• image-api-gender-estimator
• image-api-mask-estimator
• image-api-emotion-estimator

Change TTL of samples and activities

caution

The default values for each parameter are specified. It is recommended to change parameter values only if clearly necessary.

caution

The activity_ttl parameter has been removed by default, since the cleaning functionality based on the amount of stored data has been added. But it is possible to enable the functionality described here; to do this, just add the backend.activity_ttl field: “2592000” to the ./cfg/platform.values.yaml file.

File ./cfg/platform.values.yaml:

• backend.activity_ttl – duration of storing activities in the database. The value is specified in seconds. For example, 2592000 seconds (30 days)
• backend.sample_ttl – sample storage time in the database. The value is specified in seconds. For example, 2592000 seconds (30 days)

Change the number of stored activities and events

File ./cfg/platform.values.yaml:

• backend.retention_activities_count – number of stored activities per workspace
• backend.activity_handler_period – frequency of checking the number of activities in the database. The value is specified in seconds. For example, 604800 seconds (7 days)

tip

To find the optimal number of activities, you can use the following formula – a = V/(w*0.0025), where a is the number of activities per workspace; V is the desired amount of memory in GB that the activities will occupy; 0.0025 is average size of one activity in GB; w is the number of user workspaces.

File ./cfg/platform.values.yaml:

• event_service.retention_events_count – number of stored events per workspace
• event_service.event_handler_period – frequency of checking the number of events in the database. The value is specified in seconds. For example, 604800 seconds (7 days)

tip

To find the optimal number of events, you can use the following formula – e = V/(w*0.004), where e is the number of events per workspace; V is the desired amount of memory that events will occupy; 0.004 is average size of one event in GB; w is the number of user workspaces.

Send emails to SMTP server

1. Stop the deployed OMNI Platform:

   ./cli.sh platform uninstall

2. Make changes to platform-email-secret in the ./cfg/platform.secrets.json file.

3. Recreate secrets:

   ./cli.sh platform install-secrets

4. Deploy OMNI Platform:

   ./cli.sh platform install

Set the optimal number of database connections

In this section, you will learn how to calculate the number of database connections required for the event service (platform-event-service-dep) and the parameters that influence this calculation.

Why is it important to control the number of connections

• Limited Resources: Both the service and the database have limited resources (such as memory, CPU time, etc.). If too many connections are opened simultaneously, it can overload either the database or the service, leading to slowdowns or even failures.

• Performance Optimization: Having too many temporary connections can place excessive strain on the database, while too few connections can cause delays in processing requests.

• Connection Retention: In some cases, connections may remain open for extended periods, especially if the service frequently interacts with the database. For example, if workers (processes that perform tasks) are actively running, they may hold onto connections to execute subsequent requests more quickly.

What happens if the number of connections is not properly calculated

• Risk of Database Overload: If too many connections are opened simultaneously, the database may become overloaded, leading to decreased performance.

• Risk of Service Slowdown: When the database is overloaded, the processing of requests can slow down significantly.

• Potential Failures: In extreme cases, a lack of resources can cause failures, such as the database becoming unresponsive or the service beginning to throw errors.

Formula for calculating the number of connections:

(W×(PS+MO))+(PS+MO)

• Workers (W): The number of processes or threads that execute tasks in the service. The number of workers is specified in the event_service.workers parameter in the ./cfg/platform.values.yaml file. If the number is not specified, it is calculated using the formula (number of CPU cores * 2) + 1.
• Pool Size (PS): The maximum number of active connections that can be opened simultaneously. This value is set in the event_service.pool_size parameter and defaults to 5.
• Max Overflow (MO): The number of additional connections that can be opened under high load, beyond those specified in the pool. This value is set in the event_service.max_overflow parameter and defaults to 10. These connections exist only as long as the load on the service is high.

Example calculation

Suppose we have a server with an 8-core processor, and the settings parameters have not been changed. Then the number of workers (W) would be (8 * 2) + 1 = 17. Putting the values into the formula gives:

((17) * (5 + 10)) + (5 + 10) = 270 connections

This result means that under peak load, up to 270 connections to the database may be opened.

Under normal operating conditions, temporary connections (MO) can be ignored, yielding the following result:

(17×5)+5=85 connections

caution

It is not recommended to set the event_service.max_overflow parameter to 0, as this could negatively impact the service's performance under high load conditions.