12

Primero, un poco de un fondo. Hay muchas comparaciones diversas de sistemas de control de versiones distribuidas (DVCS) que comparan el tamaño del repositorio o la velocidad de referencia de las operaciones. No he encontrado ninguno que comparta el desempeño de la red de varios DVCS, y varios protocolos utilizados ... además de medir la velocidad de las operaciones (comandos) que involucran redes como 'clon', 'pull'/'fetch' o 'push'.Cómo medir el rendimiento de la red (cómo comparar el protocolo de red)

Me gustaría saber cómo haría esa comparación; cómo medir el rendimiento de la red de una aplicación, o cómo comparar el protocolo de red. Me imagino aquí, entre otros, también medir la dependencia del rendimiento tanto en el ancho de banda de la red como en la latencia (tiempo de ping) de la red; algunos protocolos sacrifican la latencia en forma de más intercambios de ida y vuelta (negociación) para enviar el "paquete" final mínimo requerido.

Preferiría soluciones que impliquen solo una computadora, si es posible. Me gustaría ver soluciones de código abierto, trabajando en Linux. Pero también me gustaría recibir respuestas más genéricas.

Preferred OS: Linux
idiomas preferidos: C, Perl, shell script


mediciones posibles:

  • número total de bytes transferidos desde el servidor al cliente y del cliente al servidor en una sola sión; esto también puede ser usado para medir sobrecarga de protocolo (ancho de banda)
  • número de de ida y vuelta (conexiones) en una transacción (latencia)
  • dependencia de la velocidad de funcionamiento de la red (tiempo que se tarda para clonar/pull/push) del ancho de banda de la red, y de la latencia de la red (tiempo de ping)

¿Cómo hacer tales mediciones (tales puntos de referencia)?


Agregado 02-06-2009:
Un simple punto de referencia (medición) sería una versión de red de time de comandos, es decir, comandos que se ejecutan me daría el número de bytes transferidos, y el número de idas y vueltas/conexiones de red durante la ejecución de un comando dado.


Agregado 09-06-2009:
Ejemplo de salida imaginaria para mencionó anteriormente solución de versión de red de time comando podría tener el siguiente aspecto:

$ ntime git clone -q git://git.example.com/repo.git 
... 
bytes sent: nnn (nn kiB), bytes received: nnn (nn kiB), avg: nn.nn KB/s 
nn reads, nn writes 

en cuenta que es solo un resultado de ejemplo, que detalla el tipo de información que uno podría querer obtener.


Agregado 09-06-2009:
Parece que algo de lo que quiero se puede lograr usando dummynet, herramienta (originalmente) para las pruebas de protocolos de red ...

+0

¿Está preguntando, cómo obtener los datos necesarios para llegar a tales puntos de referencia para un programa en red arbitrario? – none

+0

Sí, me gustaría tener como mínimo obtener el número total de bytes transferidos y quizás el número de cambios de lectura a escritura para un comando dado, algo como tiempo/tiempos para CPU y memoria, y SystemTap iotimes para E/S. –

+0

Creo que para responder realmente a su pregunta, lo ideal sería que nos diga más sobre su plataforma/sistema operativo preferido, así como su lenguaje de programación preferido. Además, una lista detallada de las mediciones que le interesen nos diría qué enfoque es más factible. – none

Respuesta

15

Si Lo entiendo correctamente, ¿está interesado básicamente en algo como Linux 'strace' (Introduction) para llamadas al sistema específicas de la red?

¿Posiblemente una combinación de un generador de perfiles y un depurador, para aplicaciones de red (es decir, 'ntrace'), que proporciona un análisis detallado de varias mediciones opcionales?

Bajo Linux, la utilidad strace se basa en gran medida de la funcionalidad proporcionada por el núcleo de Linux, a saber, la ptrace (process tracing) API:

El uso ptrace, debería ser posible obtener la mayor parte de los datos que le interesa.

En Windows, es probable que desee ver en detours con el fin de interceptar/redireccionar las llamadas a la API de Winsock para fines de inspección/evaluación comparativa.

Si realmente no necesita toda esa información de bajo nivel, probablemente también pueda usar directamente strace (en linux) y solo usarla para rastrear ciertas llamadas al sistema, por ejemplo, considere la siguiente línea que solo rastreará llamadas a la llamada al sistema open (Utilizando el parámetro adicional -o archivo, puede redireccionar toda la salida a un archivo de salida):

strace -e trace=open -o results.log

con la aprobación de una bandera -v adicional a strace, puede aumentar su nivel de detalle para conseguir información adicional (cuando se trabaja con SCM como git que se compone de muchas utilidades de shell más pequeñas y herramientas independientes, es probable que también desee examinar el uso de -f bandera para seguir también procesos bifurcados).

Por lo tanto, lo que estaría interesado en, es todo llamadas al sistema que están relacionados con sockets, a saber:

  • aceptar
  • unen
  • conectar
  • getpeername
  • getsockname
  • getsockopt
  • escuchar
  • recv
  • recvfrom
  • enviar
  • sendto
  • setsockopt
  • apagado
  • toma
  • socketpair

(en un principio, es probable que sólo desea mirar en el trato con el envío .../recv ... llamadas, aunque)

Para simplificar esto, se puede utilizar también "red" como parámetro para rastrear, lo que rastrear todas las llamadas relacionadas con la red:

traza -e = red: el seguimiento de todas las llamadas al sistema de red relacionados.

Así, una invocación strace correspondiente podría tener este aspecto:

strace -v -e trace=accept,bind,connect,getpeername,getsockname,getsockopt,listen,recv,recvfrom,send,sendto setsockopt,shutdown,socket,socketpair -o results.log -f git pull

Cuando el programa termina de ejecutarse, podrás entonces principalmente desea examinar el archivo de registro para evaluar los datos, este luego se puede lograr fácilmente mediante el uso de expresiones regulares.

Por ejemplo, cuando se ejecuta la siguiente en una cáscara de Linux: strace -v -o wget.log -e trace=connect,recv,recvfrom,send,sendto wget http://www.google.com

El archivo de registro resultante contiene mensajes como los siguientes:

  • recv (3, "HTTP/1.0 302 Encontrado \ r \ nUbicación: htt "..., 511, MSG_PEEK) = 511
  • sendto (4," \ 24 \ 0 \ 0 \ 0 \ 26 \ 0 \ 1 \ 3^\ 206 * J \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 \ 0 "..., 20, 0, {sa_family = AF_NETLINK, pid = 0, grupos = 00000000}, 12) = 20

Al mirar las páginas man para estas dos llamadas al sistema, es obvio que 511 y 20 respectivamente son la cantidad de bytes que se transfieren.Si también necesita información detallada de tiempo, puede pasar el distintivo -T a strace:

-T - tiempo de impresión empleado en cada llamada al sistema

Además, puede obtener algunas estadísticas que pasa por el indicador -c:

-c: cuente el tiempo, las llamadas y los errores para cada llamada al sistema e informe un resumen del programa exit. En Linux, esto intenta mostrar el tiempo del sistema (tiempo de CPU gastado ejecutándose en el kernel) independientemente del tiempo del reloj de pared. Si -c se usa con -f o -F (abajo), solo se guardan los totales agregados para todos los procesos rastreados.

Si también necesita examinar los datos reales procesados, es posible que desee ver en los especificadores de lectura/escritura:

-e leer = conjunto: Realizar un hexadecimal completa y volcado ASCII de todos los datos leídos del archivo descriptores enumerados en el conjunto especificado. Por ejemplo, para ver toda la actividad de entrada en el archivo , los descriptores 3 y 5 usan -e read = 3,5. Tenga en cuenta que esto es independiente del seguimiento normal de de la llamada al sistema de lectura (2) que está controlada por la opción -e trace = read. -e write = set: realiza un volcado hexadecimal y ASCII completo de todos los datos escritos en el archivo descriptores enumerados en el conjunto especificado. Por ejemplo, para ver toda la actividad de salida en el archivo los descriptores 3 y 5 usan -e write = 3,5. Tenga en cuenta que esto es independiente del seguimiento normal de la llamada al sistema write (2) que se controla mediante la opción -e trace = write.

También puede personalizar la longitud máxima de cadenas:

strsize -s: Especificar el tamaño máximo de la cadena para imprimir (el valor predeterminado es 32). Tenga en cuenta que nombres de archivo no se consideran cadenas y siempre se imprimen a todo

o cadenas han de ser objeto de dumping como hexadecimal:

-xx: Imprimir todas las cadenas en formato de cadena hexadecimal.

Por lo tanto, usar strace para mucho de esto, parece ser un buen enfoque híbrido, porque es muy fácil de hacer, pero aún hay una buena cantidad de información de bajo nivel disponible, si encuentra que necesita más nivel de información, es posible que desee considerar extender strace en su lugar o presentar solicitudes de funciones correspondientes con el strace project on sourceforge.

Sin embargo, pensando un poco más en ello, una forma menos complicada y más independiente de la plataforma de implementar una referencia de tráfico de red bastante simple, sería utilizar algún tipo de capa intermedia, entre el cliente y el servidor real: servidor que básicamente mide, analiza y redirige el tráfico al servidor real.

Más o menos como un servidor proxy (por ejemplo, SOCKS), por lo que todo el tráfico se canaliza a través de su analizador, que a su vez puede acumular estadísticas y otras métricas.

Una versión básica de algo como esto probablemente podría juntarse fácilmente usando netcat y algunos scripts de shell, pero las versiones más complejas pueden beneficiarse del uso de perl o python.

Para una implementación python de un servidor SOCKS, es posible que desee consultar pysocks.

Además, hay por supuesto twisted para Python:

Twisted es un motor de red orientada a eventos escrito en Python y licenciado bajo la licencia MIT.

Si necesita tener más información de bajo nivel, es probable que realmente desee investigar si hay interceptación de llamadas al sistema.

Si también necesita datos de eficiencia específicos del protocolo, es posible que desee consultar tcpdump.

5

posible respuesta sería utilizar SystemTap. Entre las secuencias de comandos de ejemplo hay nettop que muestra (parte de) la información de red requerida en la forma "superior", y hay una secuencia de comandos iotime que muestra la información de E/S en el formulario requerido.

Cuestiones relacionadas