Clipper 8
- vCPU
- 4 × dedicado
- RAM
- 8 GB
- Armazenamento
- 200 GB NVMe Gen4 SSD
- Transferência
- 20 TB
- IPv4 / IPv6
- 1 / /64 routed
Solução
Respostas de API abaixo de 10 ms são um problema de localização antes de serem um problema de código. A física impõe um limite de cerca de 1 ms por cada 100 km de fibra, pelo que nenhuma otimização compensa estar na cidade errada. Implemente instâncias Clipper nas regiões onde estão os seus utilizadores, mantenha o caminho crítico livre de chamadas entre regiões e meça no percentil 99 em vez da média.
| Recurso | O que realmente precisa |
|---|---|
| CPU | Núcleos dedicados de alta frequência; a latência de cauda é um problema de escalonamento |
| RAM | 8–32 GB dependendo do conjunto de trabalho |
| Disco | NVMe Gen4 |
| Rede | Regiões com capacidade Anycast para um único ponto de entrada global |
A localização é geralmente a decisão que mais importa para esta carga de trabalho — seja porque a latência domina, seja porque a jurisdição domina.
Depois, implante nessas regiões, não na mais barata.
Cores de alta frequência e fixe o processo.
Uma chamada de base de dados entre regiões anula todas as outras otimizações.
O estabelecimento de ligações domina a latência de pedidos curtos.
As médias escondem exatamente os pedidos de que os seus utilizadores se queixam.
Menos de 1 ms de tempo de servidor é alcançável para handlers simples em cores dedicadas. A latência total percebida pelo utilizador é dominada pela distância: cerca de 1 ms por 100 km em cada sentido, por isso a localização decide o resultado.
Sim, ao encaminhar cada utilizador para a instância saudável mais próxima sem atraso de propagação de DNS. Requer instâncias em várias regiões e está disponível nas nossas localizações com suporte anycast.
Normalmente, tempo de roubo de CPU em cores partilhadas, ou coleção de lixo. Cores dedicadas eliminam o primeiro; o segundo é um problema de código.