Teste de carga para pontos de serviço

Este artigo orienta-o através do processo essencial de teste de carga dos seus endpoints de Serviço de Modelos AI da Mosaic para garantir que eles possam lidar eficazmente com cargas de trabalho em produção. Ele também fornece exemplos práticos, analogias do mundo real e instruções passo a passo usando a estrutura de teste de carga de gafanhotos, para demonstrar como medir as principais métricas de desempenho, como solicitações por segundo e limites de simultaneidade, para que você possa dimensionar seus endpoints corretamente e implantar modelos com confiança para suas necessidades de negócios.

O que é um teste de carga?

Um teste de carga é um teste que simula a utilização no mundo real dos endpoints de serviço do modelo Mosaic AI para garantir que satisfaçam os seus requisitos de produção, como latência ou solicitações por segundo. Um teste de carga mede o desempenho do seu endpoint em diferentes níveis de tráfego, ajudando-o a dimensionar corretamente o endpoint para não causar 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 privados de cafeína já está a formar-se.

No início, as coisas correm bem. Alguns clientes se aproximam, fazem seus pedidos e o barista começa a preparar suas bebidas. Algumas bebidas levam 30 segundos, outras levam um minuto — dependendo da complexidade. O barista concilia vários pedidos com experiente eficiência.

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

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.

Nesta analogia:

• Cada cliente é um cliente que envia um pedido.
• O(s) barista(s) representa(m) o servidor que processa inferências de modelo uma a uma ou em paralelo.
• O tempo para fazer um pedido e servir a bebida é o tempo de implementação do modelo .
• Atrasos em falar, pagar ou encontrar o pedido são a sobrecarga da sua rede.
• Mais clientes a chegar 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 ao mesmo tempo. Se você não planejar com antecedência – por exemplo, trazendo mais baristas durante os horários de pico – as pessoas saem infelizes. O mesmo vale para seus sistemas sob carga. O teste de carga ajuda a identificar onde estão os gargalos, quanto tráfego seu sistema pode lidar e quais alterações você precisa fazer para um serviço mais suave.

Antes de executar um teste de carga em seu ponto de extremidade, você precisa:

• Compreender os componentes e conceitos relacionados ao teste de carga.
• Decida e defina os seus requisitos de produção.
• Encontre uma carga útil representativa para a estrutura de teste de carga a ser usada ao avaliar comparativamente seu endpoint.

Conceitos e definições de teste de carga

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

Requisitos de latência

Com base nos requisitos do seu negócio e do cliente, defina o desempenho ideal do seu sistema. Em um endpoint de serviço de modelo, a latência inclui o tempo de ida e volta que um cliente percebe ao enviar dados para inferência. Isso inclui latência de rede, bem como tempo de inferência. É importante garantir que os seus requisitos são realistas. Por exemplo, se o seu modelo leva 15 ms para executar a inferência quando carregado na memória, é necessário permitir tempo adicional para a latência de rede quando servido num endpoint de servidor de modelo.

Como RPS, latência e simultaneidade se relacionam?

Uma empresa tem alguns critérios definidos para o sucesso do seu sistema. Para sistemas de ML, os critérios de negócios geralmente são resultados de alta qualidade, baixa latência e alta taxa de transferência. A qualidade dos resultados está especificamente relacionada ao modelo em si, enquanto a latência e a taxa de transferência de ponta a ponta 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) está inversamente relacionada à latência e diretamente relacionada à simultaneidade.

• Quanto mais simultaneidade, maior a taxa de transferência.
• Quanto maior a latência, menor a largura de banda.

Geralmente, há uma proporção ideal de simultaneidade do lado do cliente para simultaneidade do lado do servidor para qualquer aplicativo específico. A título de exemplo, "quantos hambúrgueres pode um cozinheiro de linha preparar ao mesmo tempo". Como pode haver muitas etapas compartilhadas no processo de cozimento, o chef de linha pode ser capaz de cozinhar quatro hambúrgueres ao mesmo tempo de forma mais otimizada, em vez 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 precisa 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. Essa proporção pode ser usada para dimensionar com precisão o seu endpoint para atender às suas cargas mais exigentes.

Se o ponto de extremidade não conseguir processar solicitações com rapidez suficiente, uma linha começa a se formar. Isso é chamado de fila. A formação de uma fila normalmente resulta em latência de ponta a ponta muito maior, pois agora há tempo adicional que cada solicitação passa aguardando antes de ser processada. Se as solicitações continuarem a chegar 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 entender que tipo de pico de demanda seu endpoint pode experimentar e garantir que ele seja dimensionado corretamente com um teste de carga.

Exemplos de cenários de teste de carga

Em testes de carga, bem como em sistemas do mundo real, a relação entre simultaneidade de cliente, simultaneidade de servidor e latência é dinâmica e interdependente. Vejamos essa relação com um exemplo simples:

Cenário 1: Configuração simples

Nessa configuração, um único cliente envia solicitações sequencialmente — ele aguarda 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 provisionada: 1
• Latência de overhead: 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 provisionada

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

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

Cenário 3: Adicionar outro cliente ao sistema.

Agora você tem dois clientes fazendo solicitações para um ponto de extremidade com duas simultaneidades provisionadas. Neste caso, a solicitação de cada cliente pode ser processada de forma independente pelo endpoint simultaneamente (assumindo um balanceamento de carga perfeito). Assim, enquanto a latência total ainda é de 50 ms (40ms + 10ms), o sistema observa 40 solicitações por segundo, já que cada cliente envia 20 qps.

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

Aumentar a concorrência provisionada e o número de clientes que fazem solicitações aumenta o QPS total observado no seu sistema, sem penalização na latência.

Cenário 4: Vamos reduzir a concorrência provisionada

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

• Número de clientes: 2
• Concorrência provisionada: 2 -> 1
• Latência de overhead: 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 de uma vez. Isso força o segundo pedido a aguardar antes que o primeiro pedido tenha sido processado. A espera, ou mais corretamente, a fila da segunda solicitação pode afetar negativamente a latência do sistema. Supondo que o servidor permita o enfileiramento (habilitado por padrão no Databricks Model Serving), o segundo cliente vê uma latência de 90 ms: 10 ms (sobrecarga de rede) + 40 ms (tempo de espera em fila) + 40 ms (tempo de execução do modelo). Isto é significativamente pior do que os 50 ms vistos antes.