Pular para o conteúdo principal

Teste de carga para endpoint de serviço

Este artigo orienta você pelo processo essencial de teste de carga do seu endpoint Mosaic AI Model Serving para garantir que ele possa lidar com cargas de trabalho de produção de maneira eficaz. Ele também fornece exemplos práticos, analogias do mundo real e instruções passo a passo usando a estrutura de teste de carga Locust, para demonstrar como medir métricas de desempenho de key, como solicitações por segundo e limites de simultaneidade, para que você possa dimensionar seu endpoint corretamente e implantar modelos com confiança para as necessidades do seu negócio.

O que é um teste de carga?

Um teste de carga é um teste que simula o uso real de um endpoint servindo model Mosaic AI, garantindo que ele atenda aos seus requisitos de produção, como latência ou solicitações por segundo. Um teste de carga mede o desempenho do seu endpointsob diferentes níveis de tráfego, auxiliando no dimensionamento correto do seu endpoint para evitar atrasos.

Imagine o seguinte: são 8:00 da manhã em um dia de semana e um café popular no coração da cidade está apenas abrindo. O aroma do café fresco enche o ar. O barista está preparado, as máquinas aquecidas e a fila de clientes sem cafeína já está se formando.

No início, tudo correu bem. Alguns clientes se apresentam, fazem seus pedidos e o barista começa a preparar suas bebidas. Algumas bebidas demoram 30 segundos, outras demoram um minuto — dependendo da complexidade. O barista faz malabarismos com vários pedidos com eficiência praticada.

Mas em breve, mais pessoas chegam. Cinco clientes se transformam em dez, depois em vinte. Cada um está fazendo um pedido, esperando sua bebida e talvez conversando um pouco no balcão. O barista agora está sob pressão. Mesmo com um segundo barista entrando em ação, o sistema começa a ficar sobrecarregado — a fila cresce, os pedidos se acumulam e os clientes começam a esperar mais tempo.

Agora imagine que você está tentando medir quantas bebidas o café pode servir por minuto antes que os clientes comecem a sair frustrados. Isso é teste de carga .

Nessa analogia:

  • Cada cliente é um cliente que envia uma solicitação.
  • Os baristas representam seu servidor que processa as inferências do modelo uma a uma ou em paralelo.
  • A hora de fazer um pedido e servir a bebida é o tempo de implementação do modelo .
  • Atrasos na conversa, no pagamento ou na localização do pedido são sua sobrecarga de rede .
  • Mais clientes chegando ao mesmo tempo é concorrência de clientes .
  • Adicionar mais baristas ou mais máquinas é como aumentar a simultaneidade do servidor .

Como em qualquer bom café, há um limite para o quanto a equipe pode lidar de uma vez. Se você não planeja com antecedência — por exemplo, trazendo mais baristas durante o horário de pico — as pessoas saem infelizes. O mesmo vale para seus sistemas sob carga. Os testes de carga auxiliam a identificar onde estão os gargalos, quanto tráfego o seu sistema pode suportar e quais alterações são necessárias para um serviço mais eficiente.

Antes de executar um teste de carga no seu endpoint, é necessário:

  • Entenda os componentes e conceitos relacionados ao teste de carga.
  • Decida e defina seus requisitos de produção.
  • Encontre uma carga útil representativa para a estrutura de teste de carga a ser utilizada ao comparar o desempenho do seu aplicativo de software ( endpoint).

Conceitos e definições de teste de carga

A tabela a seguir define os conceitos relacionados ao teste de carga:

Conceito

Descrição

Concorrência de clientes (número de clientes)

O número total de clientes que enviam solicitações simultaneamente em paralelo para um endpoint. Estes são os seus clientes do café no exemplo acima.

Produção: O total de instâncias de clientes enviando tráfego para o modelo servindo endpoint.

Teste de carga: No Locust, este é o número de usuários criados que enviam tráfego para o modelo de serviço endpoint que está sendo testado.

concorrência de pontos finais

O número de processos de inferência ou instâncias de modelo que podem lidar com solicitações recebidas. Também pode ser expresso como o número de solicitações que podem ser tratadas simultaneamente pelo seu servidor de aplicativos ( endpoint). É o número de baristas no exemplo acima.

Mosaic AI Model Serving: O servidor de endpoint pode ser configurado para escalonar os tamanhos de escalonamento horizontal ( compute ). Por exemplo, ao utilizar o tamanho de endpoint de CPU “ Small ”, são criadas quatro instâncias do seu modelo no “ endpoint”.

Latência

O tempo (em milissegundos) para a conclusão de uma solicitação de ida e volta completa. Uma medida do tempo total após o cliente enviar uma solicitação até que a resposta seja recebida, incluindo o tempo de execução d endpoint e a latência da rede.

Latência PXX (P50, P90, P99)

A latência (em milissegundos) para a qual o percentil XX de solicitações foi concluído mais rápido do que. Por exemplo, um P90 de 30 ms significa que 90% de todas as solicitações foram concluídas em 30 ms ou menos.

Solicitações por segundo (RPS)

O número de solicitações concluídas por segundo. Concluído significa que uma resposta foi retornada do servidor de autenticação ( endpoint ) para o cliente.

Requisitos de latência

Com base nos requisitos do seu negócio e dos seus clientes, defina o desempenho ideal do seu sistema. Em um modelo servindo endpoint, a latência inclui o tempo de ida e volta que um cliente experimenta ao enviar dados para inferência. Isso inclui latência de rede e tempo de inferência. É importante garantir que seus requisitos sejam realistas. Por exemplo, se o seu modelo leva 15 ms para realizar a inferência quando carregado na memória, é necessário permitir tempo adicional para a latência da rede quando servido em um modelo em execução endpoint.

Como o RPS, a latência e a simultaneidade se relacionam?

Uma empresa tem alguns critérios definidos para o sucesso de seu sistema. Para sistemas de gerenciamento de dados em tempo real ( ML ), os critérios comerciais geralmente são resultados de alta qualidade, baixa latência e alta taxa de transferência. A qualidade dos resultados está especificamente relacionada ao próprio modelo, enquanto a latência de ponta a ponta e a taxa de transferência são características do sistema de serviço. A latência de ponta a ponta consiste no tempo de execução do modelo e na sobrecarga da rede. A taxa de transferência (ou solicitações ou consultas por segundo) é inversamente proporcional à latência e diretamente proporcional à simultaneidade.

  • Quanto maior a simultaneidade, maior a taxa de transferência.
  • Quanto maior a latência, menor o total.

Geralmente, há uma proporção ideal de simultaneidade do lado do cliente em relação à concorrência do lado do servidor para qualquer aplicativo. Como exemplo, “em quantos hambúrgueres um chef de linha pode trabalhar simultaneamente”. Como pode haver muitas etapas compartilhadas no processo de cozimento, o chef de linha pode ser capaz de cozinhar quatro hambúrgueres de maneira mais ideal ao invés de cozinhar apenas um de cada vez. Há um limite para essa paralelização. Em algum momento, o ato de realizar muitos atos paralelos adiciona muita latência, como se o chef precisasse adicionar queijo a 1000 hambúrgueres.

Um dos objetivos centrais de um teste de carga é determinar a proporção ideal para sua aplicação. A proporção ideal maximiza o RPS, atende aos seus requisitos de latência e evita filas. Esta relação pode ser utilizada para dimensionar com precisão o seu transformador de tensão ( endpoint ) de modo a satisfazer as suas cargas mais exigentes.

Se o site endpoint não conseguir processar as solicitações com rapidez suficiente, uma fila começará a se formar. Isso é chamado de fila. A formação de uma fila normalmente resulta em uma latência de ponta a ponta muito maior, pois agora há mais tempo que cada solicitação passa esperando antes de ser processada. Se as solicitações continuarem chegando mais rápido do que as solicitações podem ser processadas, a fila aumenta, o que aumenta ainda mais a latência. Por esse motivo, é importante compreender que tipo de pico de demanda o seu endpoint pode enfrentar e garantir que ele esteja dimensionado corretamente com um teste de carga.

Exemplos de cenários de teste de carga

Em testes de carga, assim como em sistemas do mundo real, a relação entre simultaneidade de clientes, simultaneidade de servidores e latência é dinâmica e interdependente. Vamos ver essa relação com um exemplo simples:

Cenário 1: Configuração simples

Nessa configuração, um único cliente envia solicitações sequencialmente — ele espera por uma resposta antes de emitir a próxima solicitação. Como o tempo total por solicitação é a soma da execução do modelo e da latência de sobrecarga (40 ms + 10 ms), a latência medida de ponta a ponta é de 50 ms.

  • Número de clientes: 1
  • concorrência de provisionamento: 1
  • Latência de sobrecarga: 10 ms
  • Tempo de execução do modelo 40 ms

Como resultado, o cliente conclui uma solicitação a cada 50 ms, o que equivale a 20 solicitações por segundo ou consultas por segundo.

Cenário 2: Aumentar a simultaneidade do provisionamento

Nesse caso, você tem o dobro da concorrência de provisionamento e um único cliente fazendo solicitações sequencialmente. Isso significa que a latência total ainda é de 50 ms (40 ms + 10 ms) e o sistema está vendo apenas 20 solicitações por segundo (QPS).

  • Número de clientes: 1
  • concorrência de provisionamento: 1 -> 2
  • Latência de sobrecarga: 10 ms
  • Tempo de execução do modelo 40 ms

Cenário 3: Adicionar outro cliente ao sistema.

Agora, há dois clientes fazendo solicitações a um endpoint com dois provisionamentos simultâneos. Nesse caso, a solicitação de cada cliente pode ser processada de forma independente pelo endpoint simultaneamente (supondo um balanceamento de carga perfeito). Portanto, enquanto a latência total ainda é de 50 ms (40 ms + 10 ms), o sistema observa 40 solicitações por segundo, já que cada cliente envia 20 qps.

  • Número de clientes: 1 - > 2
  • concorrência de provisionamento: 2
  • Latência de sobrecarga: 10 ms
  • Tempo de execução do modelo 40 ms

Aumentar a simultaneidade do provisionamento e o número de clientes que fazem solicitações aumenta o QPS total observado em seu sistema, sem penalidade na latência.

Cenário 4: Vamos reduzir a simultaneidade do provisionamento

Neste último cenário, o número de clientes é maior do que a simultaneidade de provisionamento. Essa configuração introduz outra variável, o enfileiramento, no sistema e seu efeito no QPS e na latência.

  • Número de clientes: 2
  • concorrência de provisionamento: 2 -> 1
  • Latência de sobrecarga: 10 ms
  • Tempo de execução do modelo: 40 ms

Aqui, você tem dois clientes fazendo solicitações simultaneamente. O endpoint, no entanto, só pode processar uma única solicitação por vez. Isso força a segunda solicitação a esperar antes que a primeira solicitação seja processada. A espera ou, mais corretamente, o enfileiramento da segunda solicitação pode afetar adversamente a latência do sistema. Supondo que o servidor permita enfileiramento (habilitado por default em Databricks servindo modelo), o segundo cliente observa uma latência de 90 ms: 10 ms (sobrecarga da rede) + 40 ms (tempo de espera na fila) + 40 ms (tempo de execução do modelo). Isso é significativamente pior do que os 50 ms vistos antes.