Pular para o conteúdo principal
Última atualização em

Configure um teste de carga para o endpoint de pesquisa vetorial.

Esta página fornece orientações, exemplos de código e um exemplo de Notebook para teste de carga do endpoint de busca vetorial. Os testes de carga ajudam a compreender o desempenho e a prontidão para produção de um endpoint de pesquisa vetorial antes de sua implantação em produção. Os testes de carga podem fornecer informações sobre:

  • Latência em diferentes níveis de escala
  • Taxa de transferência, limites e gargalos (requisições por segundo, detalhamento da latência)
  • Taxas de erro sob carga sustentada
  • utilização de recursos e planejamento de capacidade

Para obter mais informações sobre testes de carga e conceitos relacionados, consulte Teste de carga para endpoint de serviço.

Requisitos​

Antes de iniciar estes passos, você deve ter um endpoint de pesquisa de vetor implantado e uma entidade de serviço com permissões Can Query no endpoint. Consulte a etapa 1: Configurar autenticação de entidade de serviço.

Baixe e importe uma cópia dos seguintes arquivos e do Notebook de exemplo para seu workspace Databricks :

  • entrada.JSON. Este é um exemplo do arquivo input.json que especifica a carga útil que é enviada por todas as conexões concorrentes ao seu endpoint. Você pode ter vários arquivos, se necessário. Se você usar o Notebook de exemplo, este arquivo será gerado automaticamente a partir da tabela de entrada fornecida.
  • fast_vs_load_test_async_load.py. Faça o upload deste script para seu workspace (por exemplo, /Workspace/Users/<your-username>/fast_vs_load_test_async_load.py) e defina o parâmetro locust_script_path Notebook para o seu caminho. Este script gerencia a autenticação, o envio da carga útil e a coleta de métricas de depuração.
  • O seguinte exemplo de Notebook executa os testes de carga. Para obter o melhor desempenho, execute este Notebook em um cluster de nó único com um grande número de núcleos (Locust escalando em todas as CPUs disponíveis). Recomenda-se alta disponibilidade de memória para consultas com embeddings pré-gerados.

Exemplo de caderno e guia rápido​

Utilize o seguinte exemplo de Notebook para começar. Ele suporta dois modos de exploração: uma varredura gradual que testa níveis de concorrência específicos definidos pelo usuário e um modo de busca binária que encontra automaticamente o QPS máximo sustentável (ponto de ruptura) em poucos passos. Todos os parâmetros são configurados usando widgets, permitindo que o Notebook seja executado interativamente ou como um Job Databricks sem a necessidade de editar o código.

Teste de carga de gafanhotos Notebook

Abrir notebook em uma nova aba

Framework de teste de carga: Locust​

Locust é uma estrutura de teste de carga de código aberto que permite fazer o seguinte:

  • Variar o número de conexões de clientes concorrentes
  • Controle a velocidade com que as conexões são criadas.
  • Meça o desempenho endpoint ao longo do teste.
  • Detecta e utiliza automaticamente todos os núcleos de CPU disponíveis.

O Notebook de exemplo usa o sinalizador --processes -1 para detectar automaticamente os núcleos da CPU e utilizá-los totalmente.

Se o Locust estiver com gargalo na CPU, uma mensagem aparecerá na saída.

o passo 1: Configurar autenticação de entidade de serviço​

importante

Para testes de desempenho em condições semelhantes às de produção, utilize sempre a autenticação de entidade de serviço OAuth. Entidade de serviço oferece tempo de resposta até 100ms mais rápido e limites de taxa de requisição mais altos em comparação com tokens de acesso pessoal (PATs).

Criar e configurar entidade de serviço​

  1. Crie uma entidade de serviço do Databricks. Para obter instruções, consulte Adicionar entidade de serviço à sua account.

  2. Conceder permissões:

    • Acesse a página do seu endpoint de pesquisa vetorial.
    • Clique em Permissões .
    • Conceda à entidade de serviço permissões de "Pode consultar" .

  3. Criar segredo OAuth.

    • Acesse a página de detalhes da entidade de serviço.
    • Clique na guia Segredos .
    • Clique em Gerar segredo .
    • Defina o período de validade (recomenda-se 365 dias para testes de longa duração).
    • Copie imediatamente o ID do cliente e a chave secreta .

  4. Armazene suas credenciais com segurança.

    • Criar um Escopo Secreto Databricks . Para obter instruções, consulte o tutorial: Criar e usar um segredo Databricks.
    • Conforme mostrado no exemplo de código a seguir, armazene o ID do cliente da entidade de serviço como service_principal_client_id e armazene o segredo OAuth como service_principal_client_secret.
    Python
    # In a Databricks notebook
    dbutils.secrets.put("load-test-auth", "service_principal_client_id", "<CLIENT_ID>")
    dbutils.secrets.put("load-test-auth", "service_principal_client_secret", "<SECRET>")

a etapa 2: Configure seu teste de carga​

ConfiguraçãoNotebook​

Configure os parâmetros do Notebook usando os widgets na parte superior do Notebook. Ao executar o Notebook como um Job Databricks , passe esses valores como parâmetros Job . Não é necessário editar o código.

Parâmetro

Descrição

Valor recomendado

endpoint_name

Nome do seu endpointde pesquisa vetorial

Nome do seu endpoint

index_name

Nome completo do índice (catalog.schema.index)

Seu nome de índice

test_table

Tabela de origem para consultas de amostra de (catalog.schema.table)

Sua tabela de entrada de índice

query_column

Coluna de texto a ser usada para gerenciar incorporações

Deixe como text ou defina com o nome da sua coluna.

embedding_column

Coluna contendo vetores de incorporação pré-computados. Utilizado apenas para incorporações autogerenciadas.

Deixe em branco para gerenciar incorporações

sample_size

Número de consultas a serem amostradas para o teste

1000

target_concurrencies

Lista separada por vírgulas da quantidade de clientes concorrentes a serem testados.

5,10,20,50

step_duration_seconds

duração em segundos por nível de simultaneidade. Um único valor se aplica a todos os níveis, ou forneça um valor por nível como uma lista separada por vírgulas.

300 (5 minutos)

secret_scope_name

Nome do seu Escopo Secreto Databricks

Nome do seu escopo

locust_script_path

caminho do espaço de trabalho para o script fast_vs_load_test_async_load.py

/Workspace/Users/<your-username>/fast_vs_load_test_async_load.py

output_table

(Opcional) Tabela Delta para armazenar resultados em (catalog.schema.table). Criado automaticamente na primeira execução.

catalog.schema.load_test_results

run_name

Nomeie ou comente para tag esta execução para análise posterior

Um rótulo descritivo

exploration_mode

gradual percorre target_concurrencies em ordem. binary_search encontra o ponto de ruptura automaticamente (consulte Exploração do ponto de ruptura).

gradual

max_target_qps

(binary_search apenas) Limite superior para a pesquisa QPS

500

exploration_steps

(binary_search apenas) Número máximo de iterações de busca binária

8

error_rate_threshold

(binary_search apenas) Taxa máxima de erro aceitável (%) para que a passagem seja considerada um sucesso

1.0

num_results

Número de resultados a serem retornados por consulta

10

columns_to_return

Lista de colunas separadas por vírgulas a serem retornadas nos resultados da consulta (por exemplo, id,text). Deixe em branco para retornar todas as colunas.

Deixe em branco para default

gerenciar vs. autogerenciar embeddings​

O Notebook suporta tanto embeddings gerenciados (onde Databricks gera embeddings no momento da consulta) quanto embeddings autogerenciáveis (onde você passa vetores pré-computados diretamente). Configure os parâmetros adequados com base no seu tipo de índice.

Tipo de índice

Parâmetro a ser configurado

Deixe sem definir

gerenciar embeddings (Índice Delta Sync com Databricks- modelo de embedding gerenciar)

query_column — o nome da coluna de texto a ser usada como consulta

embedding_column (deixe em branco)

Incorporações autogerenciadas (índice Delta Sync ou Direct Vector Access com vetores pré-computados)

embedding_column — a coluna que contém vetores de incorporação pré-computados

query_column

nota

Para gerenciar índices de incorporação, o teste de carga mede a latência de ponta a ponta, incluindo o tempo de geração da incorporação. Se o endpoint de incorporação escalar para zero, a sobrecarga do cold-começar aparecerá na primeira execução do teste. Consulte Identificar o gargalo do modelo de incorporação para saber como isolar a latência de incorporação da latência de pesquisa.

Por que 5 a 10 minutos?​

A duração mínima do teste, de 5 minutos, é fundamental.

  • As consultas iniciais podem incluir custos indiretos de cold-começar.
  • O ponto final precisa de tempo para atingir um desempenho estável.
  • O dimensionamento automático do endpoint do modelo de serviço (se ativado) leva algum tempo para ser implementado.
  • Testes curtos não detectam o comportamento de limitação de velocidade sob carga sustentada.

A tabela a seguir mostra a duração recomendada dos testes, dependendo do seu objetivo.

Tipo de teste

Teste

Objetivos do teste

Teste rápido de fumaça

2-3 minutos

Verificar funcionalidades básicas

Linha de base de desempenho

5 a 10 minutos

Métricas confiáveis de estado estacionário

Teste de estresse

15 a 30 minutos

Identificar o esgotamento de recursos

Testes de resistência

1 a 4 horas

Degradação, estabilidade de latência

Exploração de pontos de ruptura (modo de busca binária)​

Além da varredura gradual (exploration_mode=gradual), o Notebook suporta um modo de busca binária automática que localiza o QPS máximo sustentável sem exigir que você especifique os níveis de concorrência manualmente.

Como funciona​

Defina exploration_mode=binary_search e especifique max_target_qps (por exemplo, 500). O Notebook usa a Lei de Little (concurrency = QPS × avg_latency_sec) para converter cada meta de QPS em um nível de concorrência estimado e, em seguida, executa uma pesquisa binária da seguinte forma:

  1. começar em max_target_qps / 2 (250 no exemplo).
  2. Se a taxa de erro for inferior a error_rate_threshold (sucesso), aumente o limite inferior e tente um QPS mais alto (375, depois 500 e assim por diante).
  3. Se a taxa de erro exceder o limite (falha), reduza o limite superior e tente um valor intermediário entre o último sucesso e a última falha.
  4. Repita até exploration_steps passos (default 8) ou até que o intervalo de pesquisa se reduza a 5% de max_target_qps.

A tabela a seguir mostra como a busca converge para um endpoint hipotético com um ponto de inflexão em torno de 430 QPS:

Passo

QPS alvo

Taxa de erro

Resultado

Nova gama

1

250

0,1%

Sucesso

[250, 500]

2

375

0,3%

Sucesso

[375, 500]

3

437

4,5%

Falha

[375, 437]

4

406

0,8%

Sucesso

[406, 437]

5

421

2,1%

Falha

[406, 421]

Após 5 a 8 passos, a busca converge para o ponto de ruptura — neste exemplo, aproximadamente 406 a 421 QPS — com muito menos execuções de teste do que uma varredura exaustiva.

Quando usar cada modo​

Mode

Quando usar

gradual

Você já conhece a faixa de operação esperada e deseja caracterizar o desempenho em níveis de concorrência específicos.

binary_search

Você deseja encontrar rapidamente o QPS (consultas por segundo) máximo sustentável, sem conhecer os níveis de concorrência antecipadamente.

o passo 3. Projete seu conjunto de consultas​

Sempre que possível, o conjunto de consultas deve refletir o tráfego de produção esperado da forma mais precisa possível. Especificamente, você deve tentar corresponder à distribuição esperada de consultas em termos de conteúdo, complexidade e diversidade.

  • Use consultas realistas. Não utilize textos aleatórios como "consulta de teste 1234".

  • A distribuição do tráfego de produção deve ser compatível com a previsão. Se você espera 80% de consultas comuns, 15% de consultas de frequência média e 5% de consultas pouco frequentes, seu conjunto de consultas deve refletir essa distribuição.

  • Escolha um tipo de consulta que corresponda ao que você espera ver em produção. Por exemplo, se você espera que as consultas de produção usem pesquisa híbrida ou filtros, você também deve usá-los em seu conjunto de consultas.

    Exemplo de consulta usando filtros:

    JSON
    {
      "query_text": "wireless headphones",
      "num_results": 10,
      "filters": { "brand": "Sony", "noise_canceling": true }
    }

    Exemplo de consulta usando pesquisa híbrida:

    JSON
    {
      "query_text": "best noise canceling headphones for travel",
      "query_type": "hybrid",
      "num_results": 10
    }

Diversidade de consultas e armazenamento em cache​

O endpoint de pesquisa vetorial armazena em cache vários tipos de resultados de consulta para melhorar o desempenho. Esse armazenamento em cache pode afetar os resultados dos testes de carga. Por essa razão, é importante prestar atenção à diversidade do conjunto de consultas. Por exemplo, se você enviar repetidamente o mesmo conjunto de consultas, estará testando o cache, e não o desempenho real da pesquisa.

Usar:

Quando:

Exemplo

Consultas idênticas ou poucas consultas

  • Seu tráfego de produção apresenta alta repetição de consultas (por exemplo, "produto popular").

  • Você está testando a eficácia do cache especificamente.

  • Sua aplicação se beneficia do armazenamento em cache (por exemplo, painéis com consultas fixas).

  • Você deseja medir o desempenho em cache no melhor cenário.

Um widget de recomendação de produtos que exibe "itens em alta" - a mesma consulta executada milhares de vezes por hora.

Diversas perguntas

  • Seu tráfego de produção contém consultas de usuários exclusivas (por exemplo, mecanismos de busca ou chatbots).

  • Você deseja medir o desempenho no pior caso sem cache.

  • Você quer testar o desempenho da varredura de índice, não o desempenho do cache.

  • As consultas têm alta cardinalidade (milhões de variações possíveis).

Uma ferramenta de busca em comércio eletrônico onde cada usuário digita um tipo diferente de produto ao pesquisar.

Para obter recomendações adicionais, consulte o Resumo das melhores práticas.

Opções para criar um conjunto de consultas​

A aba de código mostra três opções para criar um conjunto diversificado de consultas. Não existe uma solução única que sirva para todos. Escolha aquela que funcionar melhor para você.

  • (Recomendado) Amostragem aleatória da tabela de entrada do índice. Este é um bom ponto de partida geral.
  • Amostragem a partir de logs de produção. Este é um bom ponto de partida se você tiver logs de produção. Lembre-se de que as consultas geralmente mudam com o tempo, portanto, refresh o conjunto de testes regularmente para mantê-lo atualizado.
  • Geração de consultas sintéticas. Isso é útil se você não tiver logs de produção ou se estiver usando filtros complexos.

O código a seguir gera exemplos de consultas aleatórias da sua tabela de entrada de índice.

Python
import pandas as pd
import random

# Read the index input table
input_table = spark.table("catalog.schema.index_input_table").toPandas()

# Sample random rows
n_samples = 1000
if len(input_table) < n_samples:
    print(f"Warning: Only {len(input_table)} rows available, using all")
    sample_queries = input_table
else:
    sample_queries = input_table.sample(n=n_samples, random_state=42)

# Extract the text column (adjust column name as needed)
queries = sample_queries['text_column'].tolist()

# Create query payloads
query_payloads = [{"query_text": q, "num_results": 10} for q in queries]

# Save to input.json
pd.DataFrame(query_payloads).to_json("input.json", orient="records", lines=True)

print(f"Created {len(query_payloads)} diverse queries from index input table")

o passo 4. Teste sua carga útil​

Antes de executar o teste de carga completo, valide sua carga útil:

  1. No workspace Databricks , navegue até o seu endpoint de pesquisa vetorial.
  2. Na barra lateral esquerda, clique em Servir .
  3. Selecione seu endpoint.
  4. Clique em Usar → Consultar .
  5. Cole o conteúdo input.json na caixa de consulta.
  6. Verifique se o endpoint retorna os resultados esperados.

Isso garante que seu teste de carga medirá consultas realistas, e não respostas de erro.

o passo 5. execução do teste de carga​

Verificação e aquecimento da conectividade​

Antes do início do teste de carga, o Notebook executa duas etapas de configuração:

  1. Verificação de conectividade : Envia uma única consulta de sondagem usando as credenciais da entidade de serviço. Se o endpoint retornar um erro 401 ou 403, o Notebook falha imediatamente com um PermissionError limpo em vez de executar um teste de carga completo que produz apenas dados de erro. Isso economiza tempo quando as credenciais ou permissões estão configuradas incorretamente.

  2. Teste de aquecimento (1 minuto): execução de um breve teste de baixa concorrência que aquece os caches endpoint e valida o fluxo de requisições de ponta a ponta. Os resultados do aquecimento não são usados para métricas de desempenho. No modo de busca binária, a latência de aquecimento também é usada como linha de base para a estimativa de concorrência da Lei de Little.

Série principal de testes de carga​

O Notebook executa uma série de testes com aumento progressivo da concorrência de clientes:

  • começar: Baixa simultaneidade (por exemplo, 5 clientes simultâneos)
  • Nível intermediário: Concorrência média (por exemplo, 10, 20 ou 50 clientes)
  • Fim: alta simultaneidade (por exemplo, mais de 100 clientes)

Cada execução de teste para a duração configurada em step_duration_seconds (5 a 10 minutos recomendado).

O que o Notebook mede​

O Notebook mede e reporta o seguinte:

Latência média:

  • P50 (mediana): Metade das consultas são mais rápidas do que isso.
  • P95: 95% das consultas são mais rápidas do que isso. Esta é uma métrica key SLA .
  • P99: 99% das consultas são mais rápidas do que isso.
  • Máximo: Latência no pior caso.

Taxa de transferência métricas:

  • RPS (solicitações por segundo): Consultas bem-sucedidas por segundo.
  • Total de consultas: Número de consultas concluídas.
  • Taxa de sucesso: Percentagem de consultas bem-sucedidas.

Erros:

  • Falhas de consulta por tipo
  • Mensagens de exceção
  • Contagem de tempo limite

Armazenamento de resultados​

Se o parâmetro output_table estiver definido, o Notebook armazena uma linha por nível de concorrência (ou por pesquisa binária o passo) em uma tabela Delta Unity Catalog . A tabela é criada automaticamente na primeira execução e atualizada nas execuções subsequentes. Cada linha inclui run_name, exploration_mode, concorrência, taxas de sucesso/falha, percentis de latência, RPS e campos específicos de pesquisa binária (bs_step, bs_target_qps, bs_outcome). Isso permite comparar o desempenho ao longo do tempo usando SQL ou ferramentas BI .

Executando como um Job Databricks​

Todos os parâmetros do Notebook são definidos como dbutils.widgets, que mapeiam diretamente para os parâmetros Job Databricks . Para programar ou automatizar testes de carga:

  1. Crie um Job com o Notebook como tarefa.
  2. Defina os valores do widget como parâmetros Job . Não é necessário editar o código.
  3. Anexe a Job a um cluster de nó único com muitos núcleos de CPU (o Locust se beneficia de trabalhadores paralelos).
  4. execução sob demanda ou em um programa para testes de linha de base recorrentes.

o passo 6. Interpretar resultados​

A tabela a seguir mostra as metas para um bom desempenho:

Métrica

Destino

Comentário

Latência P95

< 500ms

A maioria das consultas é rápida.

Latência P99

< 1s

Desempenho razoável em consultas de cauda longa

Taxa de sucesso

> 99,5%

Baixa taxa de falha

Latência ao longo do tempo

Estável

Nenhuma degradação foi observada durante o teste.

Queries por segundo

Atinge a meta

O endpoint consegue lidar com o tráfego esperado.

Os seguintes resultados indicam um desempenho insatisfatório:

  • P95 > 1s. Indica que as consultas são muito lentas para uso em tempo real.
  • P99 > 3s. A latência em consultas de cauda longa prejudicará a experiência do usuário.
  • Taxa de sucesso < 99%. Fracassos em excesso.
  • Aumento da latência. Indica esgotamento de recursos ou vazamento de memória.
  • Erros limitantes da taxa (429). Indica que é necessária uma maior capacidade endpoint .

Equilíbrio entre RPS e latência​

O RPS máximo não é o ponto ideal para a Taxa de transferência de produção. A latência aumenta de forma não linear à medida que você se aproxima da Taxa de transferência máxima. Operar com a taxa máxima de requisições por segundo (RPS) geralmente resulta em uma latência de 2 a 5 vezes maior em comparação com a operação a 60-70% da capacidade máxima.

O exemplo a seguir mostra como analisar os resultados para encontrar o ponto de operação ideal.

  • O RPS máximo é de 480 com 150 clientes simultâneos.
  • O ponto de operação ideal é de 310 RPS com 50 clientes simultâneos (65% da capacidade).
  • A penalidade de latência no máximo: P95 é 4,3 vezes maior (1,5s vs. 350ms)
  • Neste exemplo, a recomendação é dimensionar o endpoint para uma capacidade de 480 RPS e operar a aproximadamente 310 RPS.

Concorrência

P50

P95

P99

RPS

Sucesso

Capacidade

5

80ms

120ms

150ms

45

100%

10%

10

85ms

140ms

180ms

88

100%

20%

20

95ms

180ms

250ms

165

99,8%

35%

50

150ms

350ms

500ms

310

99,2%

65% ← Ponto ideal

100

250ms

800ms

1,2s

420

97,5%

90% ⚠️ Quase no máximo

150

450ms

1,5s

2,5s

480

95,0%

100% ❌ RPS máximo

Operar na rotação máxima por segundo pode levar aos seguintes problemas:

  • Degradação da latência. No exemplo, o P95 leva 350ms com 65% da capacidade, mas 1,5s com 100% da capacidade.
  • Sem espaço para acomodar picos ou aumentos repentinos de tráfego. Com a capacidade em 100%, qualquer pico de demanda causa um tempo limite de inatividade. Com 65% da capacidade, um aumento de 50% no tráfego pode ser gerenciado sem problemas.
  • Aumento das taxas de erro. No exemplo, a taxa de sucesso é de 99,2% com 65% da capacidade, mas de 95,0% — uma taxa de falha de 5% — com 100% da capacidade.
  • Risco de esgotamento de recursos. Em condições de carga máxima, as filas aumentam, a pressão sobre a memória aumenta, o pool de conexões começa a saturar e o tempo de recuperação após incidentes aumenta.

A tabela a seguir mostra os pontos de operação recomendados para diferentes casos de uso.

Caso de uso

Capacidade alvo

Justificativa

Sensível à latência (busca, bate-papo)

50-60% do máximo

Priorize baixa latência P95/P99

Equilibrado (recomendações)

60-70% do máximo

Bom equilíbrio entre custo e latência.

Custo otimizado (trabalho em lote)

70-80% do máximo

Latência mais alta aceitável

Não recomendado

> 85% do máximo

Picos de latência, sem capacidade de burst.

Funções auxiliares para calcular o ponto de operação e o tamanho endpoint .​

O código a seguir representa graficamente a relação entre QPS e latência P95. No gráfico, procure o ponto onde a curva começa a se inclinar acentuadamente para cima. Este é o ponto de operação ideal.

Python
import matplotlib.pyplot as plt

# Plot QPS vs. P95 latency
qps_values = [45, 88, 165, 310, 420, 480]
p95_latency = [120, 140, 180, 350, 800, 1500]

plt.plot(qps_values, p95_latency, marker='o')
plt.axvline(x=310, color='green', linestyle='--', label='Optimal (65% capacity)')
plt.axvline(x=480, color='red', linestyle='--', label='Maximum (100% capacity)')
plt.xlabel('Queries Per Second (QPS)')
plt.ylabel('P95 Latency (ms)')
plt.title('QPS vs. Latency: Finding the Sweet Spot')
plt.legend()
plt.grid(True)
plt.show()

Identifique o gargalo do modelo de incorporação​

Se o seu índice usa embeddings gerenciais, o Notebook de teste de carga captura o tempo por componente através do parâmetro debug_level=1 em cada consulta. A tabela de resultados inclui:

  • ann_time — tempo gasto na busca aproximada do vizinho mais próximo
  • embedding_gen_time — tempo gasto na geração do embedding da consulta no endpointdo modelo de serviço
  • reranker_time — tempo gasto na reclassificação (se ativada)
  • response_time — tempo total de resposta de ponta a ponta

Se embedding_gen_time for consistentemente grande em relação a ann_time, o endpoint de incorporação é o gargalo, não o endpoint de busca vetorial. Causas comuns:

  • O endpoint do modelo de incorporação interativa tem escala para zero habilitado. Desative-o para testes de carga em produção. Veja Evite a redução da escala para zero na produção.
  • O endpoint de incorporação não possui provisionamento simultâneo suficiente para a taxa de consultas que você está testando.
  • O endpoint do modelo de incorporação é compartilhado com outras cargas de trabalho. Utilize um endpoint dedicado para testes de carga.
dica

Para isolar o desempenho da pesquisa vetorial do desempenho do modelo de incorporação, mude para incorporações autogerenciadas para testes de carga. Passe vetores pré-computados no parâmetro EMBEDDING_COLUMN em vez de consultas de texto. Isso elimina completamente a latência de incorporação da medição.

o passo 7: Dimensionar seu endpoint​

Siga a recomendação do Notebook.​

Após analisar os resultados, o Notebook solicita que você:

  1. Selecione a linha que melhor atenda aos seus requisitos de latência.
  2. Insira o RPS desejado para sua aplicação.

Em seguida, o Notebook exibe um tamanho endpoint recomendado. Ele calcula a capacidade necessária com base no seguinte:

  • Seu RPS alvo
  • Latência observada em diferentes níveis de concorrência
  • Limite de taxa de sucesso
  • Margem de segurança (normalmente 2 vezes a carga máxima esperada)

Considerações sobre escala​

Ponto final padrão:

  • Aumentar a escala automaticamente para suportar o tamanho do índice.
  • escalar manualmente para suportar Taxa de transferência
  • Reduzir automaticamente a escala quando os índices forem excluídos.
  • Reduzir manualmente a escala para diminuir a capacidade

Ponto final otimizado para armazenamento:

  • Aumentar a escala automaticamente para suportar o tamanho do índice.
  • Reduzir automaticamente a escala quando os índices forem excluídos.

o passo 8: Validar configuração final​

Após atualizar a configuração do seu endpoint:

  1. Aguarde até que o endpoint esteja pronto. Isso pode levar vários minutos.
  2. execução do teste de validação final no Notebook.
  3. Confirme se o desempenho atende às suas necessidades:
    • RPS ≥ meta Taxa de transferência
    • A latência P95 atende ao SLA.
    • Taxa de sucesso > 99,5%
    • Nenhum erro sustentado

Se a validação falhar, tente o seguinte:

  • Aumentar a capacidade endpoint
  • Otimizar a complexidade da consulta
  • Analise o desempenho do filtro
  • Verifique a configuração endpoint de incorporação

Quando refazer o teste​

Para manter a visibilidade do desempenho, é uma boa ideia executar testes de carga de referência trimestralmente. Você também deve realizar novos testes ao fazer qualquer uma das seguintes alterações:

  • Alterar padrões ou complexidade de consulta
  • Atualize o índice de pesquisa vetorial
  • Modificar configurações de filtro
  • Espere aumentos significativos no tráfego
  • implantado novo recurso ou otimizações
  • Alterar de tipos de endpoint padrão para tipos de endpoint otimizados para armazenamento

Solução de problemas​

Todas as solicitações falham com latência de aproximadamente 10 ms e respostas de 240 bytes.​

Isso indica que a entidade de serviço está recebendo uma resposta 401/403. Verificar:

  1. A entidade de serviço possui permissões de "Pode Consultar" no endpoint de busca vetorial (não apenas no índice).
  2. O Escopo Secreto contém chaves válidas service_principal_client_id e service_principal_client_secret .
  3. A chave secreta do OAuth não expirou.

O Notebook inclui uma verificação de conectividade que detecta esse problema antes de executar o teste de carga completo.

Executando várias tarefas de teste de carga no mesmo cluster​

Se você executar dois trabalhos de teste de carga simultaneamente no mesmo cluster, um dos trabalhos poderá receber tokens OAuth desatualizados ou sofrer disputa de CPU com o worker Locust do outro trabalho. Para obter resultados confiáveis, execute o teste de carga Job um de cada vez em um cluster dedicado.

Os gráficos de temporização dos componentes estão vazios​

O gráfico de temporização do componente (ann_time, embedding_gen_time, reranker_time) requer que o endpoint retorne debug_info nas respostas da consulta. Se esses gráficos estiverem vazios:

  • Verifique se você está usando o script fast_vs_load_test_async_load.py (que analisa debug_info das respostas) como o locust_script_path.
  • Algumas configurações de endpoint podem não retornar debug_info. Os índices de incorporação autogerenciados normalmente retornam ann_time e response_time , mas não embedding_gen_time ou reranker_time.

A tabela de resultados não pode ser consultada a partir de um SQL warehouse​

O Notebook grava os resultados da sessão Spark do cluster. Se um SQL warehouse mostrar 0 linhas para uma tabela que o Notebook indica como preenchida, o problema pode ser um atraso na sincronização dos metadados Unity Catalog . Aguarde alguns minutos e tente novamente, ou consulte a tabela diretamente de um Notebook conectado ao mesmo cluster.

Resumo das melhores práticas​

Configuração de teste​

  • Testes de execução com duração mínima de 5 minutos sob carga máxima.

  • Use OAuth entidade de serviço para autenticação.

  • Crie cargas úteis de consulta realistas que correspondam às consultas de produção esperadas.

  • Teste com filtros e parâmetros semelhantes aos de produção.

  • Inclua um período de aquecimento antes de realizar a medição.

  • Teste em múltiplos níveis de concorrência.

  • Monitore as latências P95/P99, não apenas as médias.

  • Teste o desempenho com e sem cache.

    Python
    # Conservative approach: Size endpoint for UNCACHED performance
    uncached_results = run_load_test(diverse_queries, duration=600)
    endpoint_size = calculate_capacity(uncached_results, target_rps=500)

    # Then verify cached performance is even better
    cached_results = run_load_test(repetitive_queries, duration=300)
    print(f"Cached P95: {cached_results['p95']}ms (bonus performance)")

Projeto do conjunto de consultas​

  • Ajuste a diversidade das suas consultas de teste à distribuição real do tráfego (consultas frequentes e raras).
  • Utilize consultas reais extraídas de logs (anonimizados).
  • Inclua diferentes níveis de complexidade de consulta.
  • Teste cenários com e sem cache e acompanhe os resultados separadamente.
  • Teste com as combinações de filtros esperadas.
  • Utilize os mesmos parâmetros que você usará em produção. Por exemplo, se você usa pesquisa híbrida em produção, inclua consultas de pesquisa híbrida. Use um parâmetro num_results semelhante ao da produção.
  • Não utilize consultas que nunca serão executadas em produção.

Otimização de desempenho​

Se a latência estiver muito alta, tente o seguinte:

  1. Use OAuth entidade de serviço (não PATs) - melhoria de 100ms
  2. Reduzir num_results - Buscar 100 resultados é mais lento do que buscar 10
  3. Otimizar filtros - Filtros complexos ou excessivamente restritivos tornam as consultas mais lentas.
  4. Verifique endpoint de incorporação — certifique-se de que não esteja dimensionado para zero ou que tenha largura de banda suficiente.

Se você estiver atingindo os limites de taxa, tente o seguinte:

  1. Aumente a capacidade endpoint - expanda seu endpoint
  2. Implemente a limitação de taxa no lado do cliente ou distribua as consultas ao longo do tempo.
  3. Utilize o agrupamento de conexões - Reutilize conexões
  4. Adicionar lógica de repetição - Usar recuo exponencial (já faz parte do SDK do Python)

Recursos adicionais​