¿Cómo se prueba si un algoritmo de congestión en particular funciona para usted? Lo pregunto porque no puedo recrear fácilmente una carga de trabajo representativa para la mayoría de los algoritmos.
Actualmente estoy analizando dos cosas, pero estoy abierto a más sugerencias:
- Los "segmentos retransmitidos" desde la salida de
netstat -s
Mi pensamiento actual es que la congestión podría provocar la caída de paquetes en algún porcentaje del tiempo, por lo que, si bien puede no haber una relación 1:1 entre la caída de un paquete y la notificación al servidor de un evento de congestión, puede haber una correlación vaga. dibujado si el cambio a un algoritmo resultó en menos paquetes descartados.
¿Esta figura muestra segmentos que fueron retransmitidos debido a la congestión o se limita a enlaces con pérdidas? Si es así (y creo que podría ser el caso), eso podría enturbiar las aguas aún más hasta el punto de que no sea una buena métrica a utilizar.
- ¿Existe una métrica disponible para medir la edad promedio de las conexiones TCP?
Mi opinión aquí es que las conexiones TCP que finalizan antes (sin un aumento en los errores y paquetes perdidos) podrían indicar que los datos se envían con menos demora.
Respuesta1
¿Esta figura muestra segmentos que fueron retransmitidos debido a la congestión o se limita a enlaces con pérdidas? Si es así (y creo que podría ser el caso), eso podría enturbiar las aguas aún más hasta el punto de que no sea una buena métrica a utilizar.
segments retransmittedincluye netstat -stodas las retransmisiones TCP del kernel por cualquier motivo, incluidas las enumeradas en su pregunta. Esas razones también podrían incluir:
- Errores de enlace
- Congestión del conmutador Ethernet
- El host local cae debido a qos o agotamiento de recursos
- Caídas del host remoto (quizás debido a alguna forma de agotamiento de recursos/Qos en el host remoto)
Los ingenieros de pruebas de rendimiento se ocupan habitualmente de todas estas variables y se aseguran de poder medirlas adecuadamente. Una de las primeras pruebas que debe realizar es asegurarse de que el cableado/la red funcione correctamente con los tamaños de paquete y las velocidades de tráfico en cuestión. Esto normalmente se hace con un dispositivo de prueba dedicado, como los de Ixia o Spirent.
Una vez que establezca una base de rendimiento de la red, estará en condiciones de ejecutar la prueba sobre la que está preguntando. Incluso si la red se probó limpia, aún debe monitorear los errores/caídas de la interfaz del conmutador durante la prueba TCP del host para asegurarse de que no sesguen sus resultados.
En cuanto a sus ideas sobre la creación de condiciones de congestión, puede resultarle útil generar intencionalmente tráfico de fondo UDP iperf justo por debajo del umbral de cola de la clase qos antes de ejecutar su tráfico TCP. Si descubre que no puede saturar el enlace que tiene, también puede resultarle útil negociar la NIC hasta 1GE o 100M.
Todo esto puede parecer complicado, y en cierto modo tal vez lo sea; sin embargo, las pruebas de qos son totalmente factibles con un enfoque y visibilidad adecuados de todos los componentes del sistema.
Respuesta2
Versión concisa:
Como señaló @ninjalj, la aplicación de carga de trabajo probablemente debería considerarse la fuente autorizada sobre si algún ajuste determinado fue beneficioso para el rendimiento de la carga de trabajo. Dependiendo de si sus requisitos son latencia o solo rendimiento general del sistema, puede tomar una decisión sobre si los cambios en el comportamiento satisfacen mejor sus requisitos de rendimiento.
En este caso, sería hacer el cambio y notar si httpdla latencia general disminuyó.
Versión más larga con ejemplos específicos:
Para profundizar, pondré esto en contexto. Miremos a Apache httpd. Puede registrar el tiempo para completar una solicitud en microsegundos y el tamaño de cada solicitud utilizando las directivas LogFormaty CustomLog. Por ejemplo:
LogFormat "%h %m %D %b" perflog
CustomLog /var/log/httpd/performance.log perflog
Lo que produce un resultado similar a este:
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
Me ocuparé únicamente de GETlas solicitudes de esto:
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 alguna razón httpdle doy un guión en lugar de un número entero 0).
Luego podemos separarlo programáticamente:
#!/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, no hagan comentarios sobre el guión, está escrito para mayor claridad, no para eficiencia. Lo anterior produce lo siguiente:
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, lo anterior ilustra por qué es importante obtener una muestra extensa. Sin embargo, los números son correctos (la solicitud de minuto y medio fue alguien generando un informe en formato Word que incluía imágenes/gráficos, para los curiosos).
Por lo tanto, convencería a Apache para que le dé una muestra extensa (probablemente en el transcurso de un día entero) de actividad normal, haga su cambio, rote los registros y luego comience a recolectar registros nuevamente (por ejemplo, esperando otro período de 24 horas).
Cada servicio (NFS, otros servidores HTTP, Samba, servidores FTP, etc.) tendrá su propia forma de recopilar información pero generalmente habráalgunomedios para registrar el tiempo y el rendimiento.