Medición del rendimiento de la red con iperf3
Hola, soy un incompetente.
Introducción
Una vez acepté datos de métricas con Elasticsearch y los visualicé con kibana, pero no era lo suficientemente ecológico como para usarlo en casa. En realidad, aunque es un sistema distribuido, la enorme cantidad de recursos que consumía era demasiado para mi mente y para mi débil servidor doméstico, así que estoy buscando otros métodos.
Es una pena activar el OOM Killer en mi pobre ordenador.
Ya tengo otras alternativas preparadas, pero si todo lo que necesito son las métricas a enviar, entonces consideraré los datos a enviar en primer lugar.
Primero, desde la capa baja antes de la capa de aplicación.
Instalar iperf3
Esta vez, trabajaré con mi ThinkPad X1C@Artix Linux como origen y mi servidor doméstico@Devuan como destino.
ThinkPad X1C@Artix Linux
$ sudo pacman -S iperf3
Servidor doméstico@Devuan
$ sudo apt install iperf3
$ sudo ufw allow 5201/tcp
$ sudo ufw reload
Para el paquete apt iperf3, se iniciará una TUI preguntando si se desea iniciar como demonio, pero esta vez elegiré n.
Con esto, los preparativos están completos.
Medición
Escuchar en el lado del servidor.
Servidor doméstico@Devuan
$ iperf -s
Enviar desde el lado del cliente. Es un entorno Wi-Fi con una pared de por medio, así que por favor, ténganme paciencia... ¿Podría decirse que obtener datos de baja calidad está jugando a mi favor?
ThinkPad X1C@Artix Linux
$ iperf3 -c DevuanSrvIP
Connecting to host DevuanSrvIP, port 5201
[ 5] local 192.168.10.118 port 41000 connected to DevuanSrvIP port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 10.8 MBytes 90.1 Mbits/sec 0 406 KBytes
[ 5] 1.00-2.00 sec 9.00 MBytes 75.5 Mbits/sec 0 484 KBytes
[ 5] 2.00-3.00 sec 9.38 MBytes 78.6 Mbits/sec 1 485 KBytes
[ 5] 3.00-4.00 sec 7.25 MBytes 60.8 Mbits/sec 0 167 KBytes
[ 5] 4.00-5.00 sec 8.25 MBytes 69.2 Mbits/sec 0 494 KBytes
[ 5] 5.00-6.00 sec 8.62 MBytes 72.3 Mbits/sec 0 496 KBytes
[ 5] 6.00-7.00 sec 9.38 MBytes 78.6 Mbits/sec 1 499 KBytes
[ 5] 7.00-8.00 sec 9.50 MBytes 79.7 Mbits/sec 0 501 KBytes
[ 5] 8.00-9.00 sec 7.62 MBytes 64.0 Mbits/sec 1 505 KBytes
[ 5] 9.00-10.00 sec 7.62 MBytes 63.9 Mbits/sec 0 508 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 87.4 MBytes 73.3 Mbits/sec 3 sender
[ 5] 0.00-10.02 sec 85.3 MBytes 71.5 Mbits/sec receiver
iperf Done.
In base a esto, se puede evaluar la calidad de la red a partir de Retr como reintentos bajo el control de ventana TCP y Cwnd como el tamaño de la ventana, y también evaluar la calidad a partir de las variaciones.
Si se quiere hacer de forma sencilla, se puede extraer solo el sender y
$ iperf3 -c DevuanSrvIP | grep "sender"
[ 5] 0.00-10.00 sec 83.8 MBytes 70.2 Mbits/sec 1 sender
Desde aquí, parece que no sería imposible pasarlo a awk mediante una tubería y enviar la información necesaria como datos de métricas.
Conclusión
Otra cosa que me interesa son los datos de métricas de E/S de disco, que parecen interesantes, pero medir regularmente el rendimiento intenso del disco solo sería una molestia, así que creo que es mejor recopilar una cantidad razonable de información de forma pequeña. No es algo a lo que suela prestar atención, pero sería interesante ver cuándo se producen esperas de E/S de forma inusual.
Me pregunto cuántos datos de métricas de aplicaciones deberían recopilarse. El alcance que hay que observar parece bastante amplio.
Cada software tiene su propia filosofía de diseño, así que se trata de desentrañar eso para ver cuánta salida se puede generar. Mientras se recopile información externamente, parece que la idea es introducir módulos y hacer que generen datos. Sin embargo, parece más flexible utilizar principalmente datos que se puedan recopilar solo desde el lado del SO.
O más bien, si las llamadas al sistema se están instruyendo a la CPU, no me parece imposible que se puedan rastrear de alguna manera, pero esa es otra historia...
Por cierto, Elasticsearch, que he instalado por diversas razones en el pasado, es bastante exigente a menos que tengas un entorno donde puedas decir '¡usa tantos recursos como quieras!'. Así que si alguna vez me encuentro en un entorno así, lo probaré de nuevo.
Sin embargo, el software de código abierto que incorpora elementos de bases de datos en memoria de este tipo es demasiado excelente, así que si voy a usarlo, necesito juzgar correctamente si vale la pena el propósito y el costo antes de introducirlo, de lo contrario, podría convertirme en un hombre que solo observa cómo se consume la RAM en exceso. Así que tendré cuidado.
Hasta la próxima. Saludos.