Como você testa se um determinado algoritmo de congestionamento está funcionando para você? Pergunto porque não posso recriar facilmente uma carga de trabalho representativa para a maioria dos algoritmos.
Atualmente estou olhando para duas coisas, mas estou aberto a mais sugestões:
- Os "segmentos retransmitidos" da saída do
netstat -s
Meu pensamento atual é que o congestionamento pode resultar em pacotes descartados em alguma porcentagem do tempo, portanto, embora possa não haver uma relação 1:1 entre um pacote sendo descartado e o servidor sendo notificado sobre um evento de congestionamento, pode haver uma correlação frouxa a ser desenhado se a mudança para um algoritmo resultasse em menos pacotes descartados.
Esta figura mostra segmentos que foram retransmitidos devido a congestionamento ou está limitada a links com perdas? Se for assim (e estou pensando que pode ser o caso), isso pode turvar ainda mais as águas a ponto de não ser uma boa métrica a ser usada.
- Existe uma métrica disponível para medir a idade média das conexões TCP?
Meu pensamento aqui é que as conexões TCP que terminam mais cedo (sem um pico de erros e pacotes descartados) podem indicar que os dados estão sendo enviados com menos atraso.
Responder1
Esta figura mostra segmentos que foram retransmitidos devido a congestionamento ou está limitada a links com perdas? Se for assim (e estou pensando que pode ser o caso), isso pode turvar ainda mais as águas a ponto de não ser uma boa métrica a ser usada.
segments retransmittedin netstat -sinclui todas as retransmissões TCP do kernel por qualquer motivo, incluindo aquelas listadas na sua pergunta. Esses motivos também podem incluir:
- Erros de link
- Congestionamento do switch Ethernet
- O host local cai devido a qos ou esgotamento de recursos
- Quedas de host remoto (talvez devido a alguma forma de esgotamento de qos/recursos no host remoto)
Os engenheiros de testes de desempenho lidam rotineiramente com todas essas variáveis e garantem que possam medi-las adequadamente. Um dos primeiros testes que você deve fazer é garantir que o cabeamento/rede funcione corretamente nos tamanhos de pacote e nas taxas de tráfego em questão. Isto normalmente é feito com um aparelho de teste dedicado, como os da Ixia ou Spirent.
Depois de definir a linha de base do desempenho da rede, você estará em condições de executar o teste sobre o qual está perguntando. Mesmo que a rede tenha sido testada limpa, você ainda deve monitorar erros/quedas de interface do switch durante o teste TCP do host para garantir que eles não distorçam seus resultados.
Quanto à sua opinião sobre a criação de condições de congestionamento, você pode achar útil gerar intencionalmente o tráfego de segundo plano iperf UDP logo abaixo do limite de enfileiramento da classe qos antes de executar o tráfego TCP. Se você achar que não consegue saturar o link que possui, também poderá achar útil negociar a NIC até 1GE ou 100M.
Tudo isto pode parecer complicado e, de certa forma, talvez seja; no entanto, o teste de QOS é totalmente viável com foco e visibilidade adequados para todos os componentes do sistema.
Responder2
Versão concisa:
Como @ninjalj apontou, o aplicativo de carga de trabalho provavelmente deveria ser considerado a fonte confiável para saber se qualquer ajuste foi benéfico para o desempenho da carga de trabalho. Dependendo se seus requisitos são de latência ou apenas de rendimento geral do sistema, você pode decidir se as mudanças no comportamento atendem melhor aos seus requisitos de desempenho.
Nesse caso, seria fazer a alteração e observar se httpda latência geral de diminuiu.
Versão mais longa com exemplos específicos:
Para elaborar, vou colocar isso em contexto. Vejamos o Apache httpd. Você pode registrar o tempo para concluir uma solicitação em microssegundos e o tamanho de cada solicitação usando as diretivas LogFormate CustomLog. Por exemplo:
LogFormat "%h %m %D %b" perflog
CustomLog /var/log/httpd/performance.log perflog
O que produz uma saída semelhante a esta:
xxx.xxx.28.20 GET 41140 86
xxx.xxx.28.20 GET 34468 28
xxx.xxx.28.20 GET 47612 1434
xxx.xxx.28.20 GET 54860 868
xxx.xxx.28.20 POST 97055 6283
xxx.xxx.28.20 GET 33754 53
xxx.xxx.28.20 GET 68964 8416
xxx.xxx.28.20 GET 1143827 11528
xxx.xxx.28.20 GET 38055 61
xxx.xxx.64.208 HEAD 6255 -
xxx.xxx.28.20 GET 36922 142
xxx.xxx.28.20 GET 51871 5581
Vou me preocupar apenas com GETpedidos para isso:
root@xxxxxxvlp14 /tmp $ grep GET /var/log/httpd/performance.log > work.log
root@xxxxxxvlp14 /tmp $ sed -i 's/-$/0/g' work.log
root@xxxxxvlp14 /tmp $
(por qualquer motivo, httpdforneça um hífen em vez de um número inteiro 0).
Podemos então separá-lo programaticamente:
#!/bin/bash
totalRequests=$(cat /tmp/work.log | wc -l )
totalTime=$(awk 'BEGIN{ count=0 } {count = count + $3} END { print count }' /tmp/work.log)
averageTime=$( printf "%.2f" $(bc -l <<< "$totalTime / $totalRequests "))
minTime=$(sort -nk 3 work.log | head -1 | awk '{print $3}')
maxTime=$(sort -rnk 3 work.log | head -1 | awk '{print $3}')
totalBytes=$(awk 'BEGIN{ count=0 } {count = count + $4} END { print count }' /tmp/work.log)
minBytes=$(sort -nk 4 work.log | head -1 | awk '{print $4}')
maxBytes=$(sort -rnk 4 work.log | head -1 | awk '{print $4}')
echo "Total Requests In Sample: $totalRequests"
echo
echo "Total Time Taken: $totalTime ms (average: $averageTime ms)"
echo "Longest Request: $maxTime ms"
echo "Shortest Request: $minTime ms"
echo
echo "Total Data Moved: $totalBytes bytes"
echo "Largest Request: $maxBytes bytes"
echo "Smallest Request: $minBytes bytes"
Por favor, não faça comentários sobre o roteiro, ele foi escrito para maior clareza, não para eficiência. O acima produz o seguinte:
Total Requests In Sample: 207
Total Time Taken: 15138613 ms (average: 73133.40 ms)
Longest Request: 1143827 ms
Shortest Request: 1788 ms
Total Data Moved: 409825 bytes
Largest Request: 20476 bytes
Smallest Request: 0 bytes
Obviamente, o que foi dito acima ilustra por que é importante obter uma amostra extensa. Os números estão corretos (o pedido de um minuto e meio foi alguém gerando um relatório em formato Word que incluía imagens/gráficos, para os curiosos).
Então, você persuadiria o Apache a fornecer uma amostra longa (provavelmente ao longo de um dia inteiro) de atividade normal, faria sua alteração, rotacionaria os logs e começaria a coletar logs novamente (por exemplo, aguardando outro período de 24 horas).
Cada serviço (NFS, outros servidores HTTP, Samba, servidores FTP, etc.) terá sua própria maneira de coletar informações, mas geralmente haveráalgunsmeios de registrar tempo e rendimento.