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