O modelo de proxy necessariamente introduz uma sobrecarga de desempenho adicional, que vem de três fontes principais:
- Atraso na conversão do protocoloConversão do formato JSON: a conversão do formato JSON adiciona uma média de 15 a 20 ms ao tempo de processamento
- contagem de saltos de redeMais um handshake TCP/negociação TLS aumenta a latência em cerca de 10 ms
- Perda de análise de scriptO interpretador Bash é executado com menos eficiência do que uma linguagem compilada.
Recomendações de otimização:
- Topologia de implantaçãoReduzir a latência da rede implantando agentes e servidores na mesma região geográfica (por exemplo, ambos implantados na região AWS us-east-1)
- Seleção de hardwareSeleção de CPUs com suporte ao conjunto de instruções AES-NI para acelerar a criptografia e a descriptografia de TLS
- ajuste de parâmetros: Ajuste do kernel do Linux
net.ipv4.tcp_tw_reusee outros parâmetros para melhorar a reutilização da conexão - Soluções de vigilância: através de
time curl -vComando Medição detalhada do consumo de tempo por estágio
Os dados medidos mostram que, em uma instância EC2 de 4 núcleos e 8G, a latência adicional trazida pelo proxy pode ser controlada em 50 ms, com uma perda de throughput de cerca de 7%, o que é aceitável na maioria dos cenários de aplicativos.
Essa resposta foi extraída do artigoProxy do Claude: ferramenta de proxy para converter a API do Claude para o formato OpenAIO
