Guia de desempenho e escalabilidade

O sistema Oz consiste em muitos componentes interconectados.

Componentes Oz

A maioria dos componentes requer escalonamento para garantir a funcionalidade durante um aumento em APM. O esquema abaixo representa como o sistema processa uma análise usando software de suporte.

Representação aproximada do fluxo de análise

Este guia explica como escalonar componentes e melhorar o desempenho tanto em implantações Docker quanto Kubernetes.

Para implantações em K8s, use HPA. Nos valores do chart, você encontrará o use_hpa parâmetro para cada componente que suporta HPA.

Escalonamento de Oz BIO e Celery-TFSS

BIO é o componente que mais consome recursos, pois executa o processamento de análise de mídia.

• O componente BIO pode levar até 10 minutos para iniciar (aplicável para versões <1.2).

• Escalonar nós BIO pode ser desafiador durante um aumento rápido em APM.

• Para instalações Docker, planeje o número necessário de componentes para lidar com picos de carga.

• Para instalações Kubernetes, agende a criação de pods BIO adicionais para gerenciar a demanda usando cronjobHpaUpdater em values.yaml.

Requisitos de nó

• A CPU deve oferecer suporte a avx, avx2, fma, sse4.1 e sse4.2.

• Se a CPU oferecer suporte a avx512f instruções: para aumentar ligeiramente o desempenho, você pode usar uma imagem BIO específica.

• Recomenda-se usar CPU Intel. CPUs AMD também são suportadas, mas exigem configuração adicional.

• Para melhor desempenho, cada BIO deve residir em um nó dedicado com recursos reservados.

As expectativas de APM podem variar, dependendo da velocidade das CPUs (GHz).

Recomendado: 2,5+ GHz.

Para melhor desempenho: 3,0+ GHz.

Escalonamento

Cada instância BIO pode lidar com um número ilimitado de solicitações simultâneas. No entanto, à medida que o número aumenta, o tempo de execução de cada solicitação cresce.

A atribuição de análises às instâncias BIO é gerenciada por celery-tfss workers. Cada celery-tfss instância é configurada para lidar com 2 análises simultaneamente, pois isso proporciona desempenho e tempo de análise ideais.

Para instalações Kubernetes, esse comportamento pode ser ajustado usando o parâmetro concurrency em values.yaml. Na configuração padrão, o número de celery-tfss instâncias deve corresponder ao número de BIOs.

O número necessário de BIOs pode ser calculado usando a fórmula abaixo, com base no tempo médio de análise e no número esperado de análises:

Aqui,

• N(BIO) é o número necessário de nós BIO

• n(APM) é o número esperado de APM,

• t(análise) é a duração média medida de uma única análise (3 segundos por padrão),

• C é a concorrência (2 por padrão).

Para um grande número de solicitações envolvendo arquivos .zip (por exemplo, se você usa Web SDK), pode ser necessário um escalonamento adicional do celery-preview_convert serviço.

Banco de dados

Oz API não foi projetada para ser um sistema de armazenamento de análises de longo prazo, portanto você pode encontrar um tempo de resposta da API mais longo após 10–30 milhões de pastas armazenadas no banco de dados (dependendo do desempenho do banco de dados). Assim, recomendamos arquivar ou excluir dados da API após um ano de armazenamento.

Para o banco de dados autogerenciado, serão necessários os seguintes recursos:

API

• CPU: 4 núcleos (até 8),

• RAM: 8 GB (até 16),

• armazenamento SSD.

1:N (Collection)

• CPU: 4 núcleos (até 8),

• RAM: igual ao tamanho do banco de dados,

• armazenamento SSD.

Parâmetros do banco de dados PostgreSQL

• idle_in_transaction_session_timeout: 60s,

• max_connections: 2000 (pode variar dependendo do número de chamadas da API),

• shared_buffers: 2 GB (quantidade de RAM dividida por 2),

• effective_cache_size: 6 GB (RAM – 2 GB),

• maintenance_work_mem: 512 MB,

• checkpoint_completion_target: 0.9,

• wal_buffers: 16 MB,

• default_statistics_target: 100,

• random_page_cost: 1.1,

• effective_io_concurrency: 200,

• work_mem: 16 MB,

• min_wal_size: 1 GB,

• max_wal_size: 4 GB,

• max_worker_processes: 4 (igual ao número de CPUs),

• max_parallel_workers_per_gather: 2 (número de CPUs dividido por 2),

• max_parallel_workers: 4 (igual ao número de CPUs),

• max_parallel_maintenance_workers: 2 (número de CPUs dividido por 2),

• Se o banco de dados estiver em Docker, defina shm_size: '1gb'.

• O banco de dados 1:N requer a Pgvector extensão.

• Não crie índices para o banco de dados 1:N, pois eles reduzirão a precisão.

• Para 1:N, o paralelismo é crucial.

• Aumente a RAM junto com o crescimento do seu banco de dados.

• Se o número de conexões ativas permitir permanecer dentro do shared_buffers limite, você pode aumentar work_mem.

Para aumentar o desempenho da API, considere usar esta lista de índices:

Índices do Gateway

CREATE INDEX CONCURRENTLY gw_analyse_abstract_company_id_idx ON public.gw_analyse_abstract USING btree (company_id);
CREATE INDEX CONCURRENTLY gw_analyse_abstract_folder_id ON public.gw_analyse_abstract USING btree (folder_id);
CREATE INDEX CONCURRENTLY gw_analyse_abstract_time_updated_state_idx ON public.gw_analyse_abstract USING btree (time_updated) WHERE (state = 'PROCESSING'::analyse_state);
CREATE INDEX CONCURRENTLY idx_gw_analyse_abstract_state_time_updated ON public.gw_analyse_abstract USING btree (state, time_updated);
CREATE INDEX CONCURRENTLY gw_analyse_collection_collection_id_idx ON public.gw_analyse_collection USING btree (collection_id);
CREATE INDEX CONCURRENTLY gw_analyse_collection_person_media_association_person_id_idx ON public.gw_analyse_collection_person_media_association USING btree (person_id);
CREATE INDEX CONCURRENTLY gw_analyse_cpma_media_association_id_idx ON public.gw_analyse_collection_person_media_association USING btree (media_association_id);
CREATE INDEX CONCURRENTLY gw_analyse_result_group_image_analyse_id_idx ON public.gw_analyse_result_group_image USING btree (analyse_id);
CREATE INDEX CONCURRENTLY gw_analyse_result_group_image_image_id_idx ON public.gw_analyse_result_group_image USING btree (image_id);
CREATE INDEX CONCURRENTLY gw_analyse_result_image_media_association_id_idx ON public.gw_analyse_result_image USING btree (media_association_id);   
CREATE INDEX CONCURRENTLY gw_analyse_source_media_association_analyse_id_idx ON public.gw_analyse_source_media_association USING btree (analyse_id);
CREATE INDEX CONCURRENTLY gw_analyse_source_media_association_source_image_id_idx ON public.gw_analyse_source_media_association USING btree (source_image_id);   
CREATE INDEX CONCURRENTLY gw_analyse_source_media_association_source_shots_set_id_idx ON public.gw_analyse_source_media_association USING btree (source_shots_set_id);
CREATE INDEX CONCURRENTLY gw_analyse_source_media_association_source_video_id_idx ON public.gw_analyse_source_media_association USING btree (source_video_id);
CREATE INDEX CONCURRENTLY gw_collection_company_id_idx ON public.gw_collection USING btree (company_id);
CREATE INDEX CONCURRENTLY gw_collection_creator_id_idx ON public.gw_collection USING btree (creator_id);
CREATE INDEX CONCURRENTLY gw_collection_person_collection_id_idx ON public.gw_collection_person USING btree (collection_id);
CREATE INDEX CONCURRENTLY gw_collection_person_image_person_id_idx ON public.gw_collection_person_image USING btree (person_id);
CREATE INDEX CONCURRENTLY gw_folder_company_id_idx ON public.gw_folder USING btree (company_id) WHERE (NOT is_archive);
CREATE INDEX CONCURRENTLY gw_folder_event_session_id_idx ON public.gw_folder USING btree (((meta_data ->> 'event_session_id'::text))) WHERE (NOT is_archive);
CREATE INDEX CONCURRENTLY gw_folder_resolution_author_id_idx ON public.gw_folder USING btree (resolution_author_id);
CREATE INDEX CONCURRENTLY gw_folder_resolution_comment_fts_idx ON public.gw_folder USING gin (to_tsvector('english'::regconfig, (resolution_comment)::text));
CREATE INDEX CONCURRENTLY gw_folder_time_created_folder_id_idx ON public.gw_folder USING btree (time_created DESC, folder_id DESC);
CREATE INDEX CONCURRENTLY gw_folder_time_created_folder_id_nonarchive_idx ON public.gw_folder USING btree (time_created DESC, folder_id DESC) WHERE (is_archive = false);
CREATE INDEX CONCURRENTLY gw_folder_time_created_idx ON public.gw_folder USING btree (time_created DESC);
CREATE INDEX CONCURRENTLY gw_folder_time_created_nonarchive_idx ON public.gw_folder USING btree (time_created DESC) WHERE (is_archive = false);
CREATE INDEX CONCURRENTLY gw_folder_user_id_idx ON public.gw_folder USING btree (user_id);
CREATE INDEX CONCURRENTLY idx_gw_folder_transaction_id ON public.gw_folder USING btree (company_id, ((meta_data ->> 'transaction_id'::text))) WHERE (NOT is_archive);
CREATE INDEX CONCURRENTLY idx_gw_folder_user_id_time_created ON public.gw_folder USING btree (user_id, time_created);
CREATE INDEX CONCURRENTLY gw_folder_image_folder_id_idx ON public.gw_folder_image USING btree (folder_id);
CREATE INDEX CONCURRENTLY gw_folder_report_author_id_idx ON public.gw_folder_report USING btree (author_id);
CREATE INDEX CONCURRENTLY gw_folder_report_folder_id_idx ON public.gw_folder_report USING btree (folder_id);
CREATE INDEX CONCURRENTLY gw_folder_report_report_template_id_idx ON public.gw_folder_report USING btree (report_template_id);
CREATE INDEX CONCURRENTLY idx_gw_folder_shots_set_folder_id ON public.gw_folder_shots_set USING btree (folder_id);
CREATE INDEX CONCURRENTLY gw_folder_video_folder_id_idx ON public.gw_folder_video USING btree (folder_id);
CREATE INDEX CONCURRENTLY gw_logging_event_record_session_id_idx ON public.gw_logging_event_record USING btree (session_id);
CREATE INDEX CONCURRENTLY gw_logging_event_record_time_created_idx ON public.gw_logging_event_record USING btree (time_created);
CREATE INDEX CONCURRENTLY gw_logging_event_record_timemark_idx ON public.gw_logging_event_record USING btree (timemark);
CREATE INDEX CONCURRENTLY gw_logging_event_session_time_created_idx ON public.gw_logging_event_session USING btree (time_created);
CREATE INDEX CONCURRENTLY gw_logging_event_session_user_id_idx ON public.gw_logging_event_session USING btree (user_id);
CREATE INDEX CONCURRENTLY gw_logging_event_session_time_updated_idx ON gw_logging_event_session(time_updated);
CREATE INDEX CONCURRENTLY gw_report_template_company_id_idx ON public.gw_report_template USING btree (company_id);
CREATE INDEX CONCURRENTLY gw_report_template_name_company_id_idx ON public.gw_report_template USING btree (name, company_id);
CREATE INDEX CONCURRENTLY gw_report_template_attachment_filename_report_template_id_idx ON public.gw_report_template_attachment USING btree (filename, report_template_id);
CREATE INDEX CONCURRENTLY gw_report_template_attachment_report_template_id_idx ON public.gw_report_template_attachment USING btree (report_template_id);
CREATE INDEX CONCURRENTLY gw_role_abstract_user_company_id_idx ON public.gw_role_abstract_user USING btree (company_id);
CREATE INDEX CONCURRENTLY gw_role_email_restore_code_user_id_idx ON public.gw_role_email_restore_code USING btree (user_id);
CREATE INDEX CONCURRENTLY gw_role_session_old_access_token_idx ON public.gw_role_session USING btree (old_access_token);
CREATE INDEX CONCURRENTLY gw_role_session_user_id_idx ON public.gw_role_session USING btree (user_id);
CREATE INDEX CONCURRENTLY gw_role_user_photo_user_id_idx ON public.gw_role_user_photo USING btree (user_id);
CREATE INDEX CONCURRENTLY gw_shots_set_frame_shots_set_id_idx ON public.gw_shots_set_frame USING btree (shots_set_id);
CREATE INDEX CONCURRENTLY gw_utils_audit_actor_id_idx ON public.gw_utils_audit USING btree (actor_id);
CREATE INDEX CONCURRENTLY gw_utils_media_company_id_idx ON public.gw_utils_media USING btree (company_id);

Para ambientes com alta carga, alcançar o melhor desempenho exige ajuste preciso do banco de dados. Entre em contato com nosso suporte para assistência.

Desempenho dos gestos

A duração da análise depende do gesto usado para Liveness. Liveness passiva gestos geralmente são analisados mais rapidamente, enquanto Liveness ativa gestos oferecem maior precisão, mas levam mais tempo. Quanto mais tempo o gesto levar, mais tempo levará a análise.

Esta tabela representa a duração da análise para diferentes gestos.

Gesto	Tempo médio de análise	50º percentil
[video_selfie_blank]	5.491	4.984
[video_selfie_down]	11.051	8.052
[video_selfie_eyes]	9.953	7.399
[video_selfie_high]	10.937	8.112
[video_selfie_left]	9.713	7.558
[video_selfie_right]	9.95	7.446
[video_selfie_scan]	9.425	7.29
[video_selfie_smile]	10.25	7.621

Desempenho dos métodos da API

O desempenho da API depende principalmente de banco de dados e armazenamento desempenho. A maioria dos métodos da API usa um banco de dados para retornar resultados. Assim, para manter baixo o tempo de resposta da API, recomendamos usar um banco de dados de alto desempenho. Além disso, para reduzir o número de solicitações por resultados de análise via /api/foldersmétodos, considere o uso de callback webhook.

Se você usar S3, verifique também seu desempenho. Execute POST api/folders com uma única mídia de ~3 MB. Depois disso, verifique o tempo de upload nos logs, “Files saved to storage for X seconds”. X deve ser 0,5 ou menos; se for 2 ou mais, algumas operações da API podem levar a timeouts.

Abaixo está uma lista de práticas recomendadas e não recomendadas para o uso dos métodos da Oz API.

/authorize

Não

• Atualize o token expirado quando possível.

• Monitore a expiração do token.

• Use o service token apenas quando apropriado.

Evite

• Fazer solicitações com um token expirado.

• Criar um novo token em vez de atualizar um que está expirando.

• Solicitar um novo token em cada chamada da API.

/api/companies

Não

• Crie uma nova company nomeada para sua implantação.

Evite

• Usar o padrão system_company.

/api/users

Não

• Crie contas nomeadas para os usuários.

• Crie uma conta de serviço nomeada separada para cada processo de negócio.

Evite

• Compartilhar contas entre usuários.

• Criar um novo usuário para cada solicitação de análise.

/api/healthcheck

Evite

• Usar healthcheck com muita frequência, pois isso pode sobrecarregar o sistema com verificações internas.

GET /api/folders

Não

• Sempre use os parâmetros de consulta com limite de tempo: time.created.min e time.created.max.

• Use o total_omit=true parâmetro de consulta.

• Use o folder_id parâmetro de consulta quando o ID da pasta for conhecido.

• Use o technical_meta_data parâmetro de consulta no caso de você ter meta_data definido.

• Use o limit parâmetro de consulta quando possível.

Evite

• Usando o with_analyzes=true parâmetro de consulta quando ele for desnecessário, em solicitações envolvendo longos períodos de tempo ou durações não especificadas.

• Usando o technical_meta_data parâmetro de consulta com parâmetros adicionais não especificados ou período de tempo.

POST /api/folders

Evite

• Colocar dados demais no payload meta_data.