¿Alguien está al tanto de los parámetros / mediciones de rendimiento para usar un socket local de Unix para la comunicación entre procesos?
Quiero ilustrar el beneficio de rendimiento de tener una instancia de base de datos local en el mismo servidor que el software que solicita los datos de la base de datos en lugar de tener que comunicarse a través de un enlace de red, especialmente uno como Gigabit Ethernet, que espero sea bastante lento Hablando relativamente.
Al buscar en línea, encontré algunos puntos de referencia que mostraban el número de operaciones por segundo, pero no el rendimiento por segundo (es decir, 12 GB / s).
Entiendo que el rendimiento variará debido a cosas como quizás el rendimiento de la memoria en un sistema dado u otras características de hardware, pero solo se necesita una idea aproximada.
Esto no se refiere al rendimiento del TCP local ni a una comparación con eso.
fuente
Respuestas:
Puede usar socat para una simple prueba de velocidad de socket de UNIX.
A continuación se muestran los resultados que obtengo en mi computadora portátil:
Memoria a disco (SSD), a través del zócalo UNIX
Memoria a memoria, a través del zócalo UNIX
Memoria a / dev / null (descartar), a través del socket UNIX
/ dev / zero a / dev / null, a través del socket UNIX
Como puede ver, incluso el rendimiento de prueba de "memoria a disco" es 545MB / s (es decir, ~ 4360MiB / s), que está muy por delante de un rendimiento teórico máximo para la conexión Ethernet de 1GB (que es ~ 1000/8 = 125MB / s, ni siquiera considerando cualquier sobrecarga de protocolo).
PD
Tenga en cuenta que esta es solo una prueba simple usando algunas herramientas simples, y no un punto de referencia real y adecuado .
fuente
He tenido que ayudar a las personas a comprender el impacto de las pilas de aplicaciones de varios niveles.
Para el aspecto de las comunicaciones TCP, utilizo las diferencias en RTT (tiempo de ida y vuelta).
Para un solo nivel, puede comparar la dirección IP local (en una NIC) con lo0 (loopback).
Para los niveles múltiples, puede comparar / calcular las direcciones "más distantes", por ejemplo, los niveles múltiples pueden ser dos VM en el mismo host, o pueden ser hosts diferentes en el mismo centro de datos, o pueden estar en diferentes centros de datos (tal vez solo 500 metros de distancia, pero aún diferente).
FYI: para muchas aplicaciones, las diferencias de RTT son insignificantes, pero para las aplicaciones que hacen de 10 a 100 de miles de mensajes pequeños para el tiempo de RTT de la aplicación pueden convertirse en un cuello de botella.
(He visto situaciones en las que el "lote tardó casi 6 horas más en varios niveles cuando el RTT fue 0,25 milisegundos más, en comparación con un solo nivel)
Entonces, banco de pruebas simple:
los
Y mi programa de monitoreo es tcpdump, con la opción -ttt
Entonces, en dos ventanas diferentes tengo tcpdump ejecutándose:
Para los tiempos "locales": tcpdump -i lo0 -n -ttt port 80 Y para el "remoto" tcpdump -I en1 -n -ttt port 80
En los datos a continuación, el objetivo no es hacer ningún análisis, sino mostrar cómo puede identificar 'diferencias' en el tiempo requerido para completar las transacciones. Cuando el rendimiento de una aplicación son transacciones en serie, el rendimiento por "seg | min | hora" se ve afectado por el tiempo total requerido para las "respuestas". He encontrado esto más fácil de explicar usando el concepto de RTT: tiempo de ida y vuelta.
Para un análisis real, hay cosas adicionales a tener en cuenta. Entonces, las únicas líneas que mostraré son el protocolo de enlace TCP inicial, y el primer paquete saliente y el ACK de regreso. Para la comparación, compare los tiempos delta de cuánto tiempo antes de que regrese la "respuesta".
127.0.0.1
192.168.129.63
tenga en cuenta el 01.XXXXXX - para el sueño de un segundo en la interfaz "lo0"
192.168.129.72
máquina virtual en el mismo host: tenga en cuenta que la hora comienza a las 00.000000: se muestra el primer paquete (y el 01.XXXXXX para las otras dos direcciones a continuación)
192.168.129.254
mi enrutador: fuera del host, no una máquina virtual.
192.168.129.71
misma conexión que 192.168.129.72, pero esto está 'ocupado' mientras que '72' está inactivo. Espero que los apretones de manos iniciales sean casi idénticos
saltos múltiples
este es el mismo host, el mismo resultado de apache, pero ahora a través de la interfaz externa (6 saltos IP, en lugar de directo): ahora puede obtener el efecto de RTT de larga distancia. (ps, modifiqué la dirección IP ligeramente). Más importante: observe que hay dos paquetes salientes después del apretón de manos inicial antes del primer ACK después de que vuelve un apretón de manos.
Entonces, en lugar de RTT de 25 ms, piense que el RTT es de 250 microsegundos, en comparación con 25 microsegundos, y tiene transacciones de 500k (eso equivale a solo 120 a 125 segundos adicionales en comparación con el local, y el rendimiento es, en mi opinión, comparable. Pero con 50 millones de transacciones (como lo hice en una situación de la vida real) gana 12500 segundos adicionales, lo que agrega alrededor de 3.5 horas adicionales para "literalmente" el mismo trabajo (y parte de la solución para este caso era hacer que los paquetes fueran más grandes) el tamaño promedio era originalmente de 400-450 bytes).
Otra cosa que "me gusta" sobre el uso de tcpdump es que es un programa que generalmente está disponible. No es necesario instalar nada adicional.
fuente