Skip to main content
Version: 1.18.2 (latest)

Basic settings

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.