¿Qué tan lentos son los sockets TCP en comparación con los named pipes en Windows para localhost IPC?
performance named-pipes (6)
Estoy desarrollando un TCP Proxy para ponerlo frente a un servicio TCP que debe manejar entre 500 y 1000 conexiones activas desde Internet salvaje.
El proxy se ejecuta en la misma máquina que el servicio, y es principalmente transparente. El servicio en su mayoría desconoce el proxy, la única excepción es la notificación de la dirección IP remota real de los clientes.
Esto significa que, para cada socket TCP entrante abierto, hay dos sockets más en el servidor: el segundo del par en el Proxy, y el del servicio real detrás del proxy.
Los tamaños de ventana de envío y recepción en los dos zócalos Proxy están configurados en 1024 bytes.
¿Cuáles son las implicaciones de rendimiento en esto? ¿Qué tan lenta es esta configuración? ¿Debo poner un poco de esfuerzo en cambiar el servicio para usar Named Pipes (u otro mecanismo IPC), o un socket TCP localhost es en su mayor parte un IPC eficiente?
La fusión de las dos aplicaciones no es una opción. En este momento estamos atrapados con la configuración de dos procesos.
EDITAR : El motivo de tener dos procesos separados en el mismo hardware es 100% económico. Tenemos un solo servidor, y no estamos planeando obtener más (sin dinero).
El servicio TCP es un software heredado en Visual Basic 6 que creció más allá de nuestras expectativas. El proxy es C ++. No tenemos el tiempo, el dinero ni la mano de obra para reescribir y migrar el código VB6 a un entorno de programación moderno.
El proxy es nuestro intento de mitigar un problema de rendimiento específico en el servicio, un ataque DDoS que estamos recibiendo de vez en cuando.
El proxy es de código abierto, y aquí está el código fuente del proyecto .
¿Cuál es el motivo para tener un proxy en la MISMA máquina, solo curiosidad?
De todas formas:
Existen varios métodos para IPC, TCP / IP, los llamados Pipes son comparables en velocidad y complejidad. Si realmente quieres algo que se adapte bien y casi no tenga gastos generales, utiliza la memoria compartida. Se usa mejor en combinación con un algoritmo de bloqueo libre para avanzar los punteros (o usa un buffer para cada lector (el proxy / el servicio) y el escritor (el servicio / el proxy)).
En el escenario que describe, las conexiones TCP locales son muy poco probable que sea un cuello de botella. Esto introducirá algunos gastos indirectos, por supuesto, pero esto debería ser insignificante a menos que su CPU ya esté en funcionamiento.
Supongo que si el uso de la CPU de su servidor normalmente es inferior al 50% aproximadamente (con el proxy en su lugar) no vale la pena preocuparse por minimizar la sobrecarga asociada con las conexiones TCP locales.
Si el uso de la CPU es regularmente superior al 80%, probablemente debería estar haciendo algunos perfiles. Comenzaría por comparar la carga de la CPU (o, mejor aún, el rendimiento, si se puede medir de manera significativa) cuando el proxy está en su lugar a cuando no lo está. A menos que el proxy realice algún proceso complicado, la sobrecarga asociada con las conexiones TCP extra es probablemente una fracción significativa de la sobrecarga total introducida por el proxy, por lo que debería darle al menos una estimación de orden de magnitud de cuánto '' d ganancia mediante el uso de una forma más eficiente de IPC.
Para cualquiera que venga a leer esto más tarde, quiero agregar algunos hallazgos que responden a la pregunta original.
Para una utilidad que estamos desarrollando tenemos una clase de red que puede usar canalizaciones con nombre, o TCP con las mismas llamadas.
Aquí hay una transferencia de archivo de bucle típico en nuestro sistema de prueba:
Tiempo de transferencia de TCP / IP: 2,5 segundos
Canalizaciones con nombre Tiempo de transferencia: 3.1 segundos
Ahora, si sale de la máquina y se conecta a una computadora remota en su red, el rendimiento de las tuberías con nombre es mucho peor:
Tiempo de transferencia de TCP / IP: 12 segundos
Canalizaciones con nombre Tiempo de transferencia: 2.5 minutos (¡Sí, minutos!)
Me doy cuenta de que este es solo un sistema (Windows 7) Pero creo que es un buen indicador de lo lento que pueden ser los tubos con nombre ... y parece que TCP es el camino a seguir.
Sé que este tema es muy antiguo, pero todavía era relevante para mí, y tal vez otros lo vean en el futuro también.
Implementé IPC entre Excel (VBA) y otro proceso en la misma máquina, tanto a través de una conexión TCP como a través de Named Pipes.
En una prueba de rendimiento rápido, envié un mensaje que consistía en 26 bytes desde el cliente (Excel) al servidor (no Excel), y esperé el mensaje de respuesta del otro proceso (que consistía en 12 bytes en el ejemplo). Ejecuté esto una tonelada de veces en un bucle y medí el tiempo promedio de ejecución.
Con TCP en localhost (Windows 7, no fastpath), una "conversación" (solicitud + respuesta) tomó alrededor de 300-350 microsegundos. Especialmente el envío de datos fue bastante lento (enviar los 26 bytes tomó alrededor de 200 microsegundos a través de TCP). Con Named Pipes, una conversación tomó alrededor de 60 microsegundos en promedio, por lo que MUCHO más rápido.
No estoy del todo seguro de por qué la diferencia era tan grande. El entorno corporativo en el que probé tiene un cortafuegos estricto, inspecciones de paquetes y otras cosas, así que PIENSO que esto pudo deberse a que incluso la conexión TCP basada en el localhost pasó por medidas de seguridad que la ralentizaron significativamente, mientras que las tuberías con nombre no lo hicieron .
TL: DR: En mi caso, las tuberías con nombre eran alrededor de 5-6 veces más rápidas que TCP para paquetes pequeños (aún no se han probado con las más grandes)
Será lo mismo (o al menos no mensurablemente diferente). Winsock es lo suficientemente inteligente como para saber si está hablando con un socket en el mismo host y, en ese caso, cortocircuitará casi todo lo que está debajo de IP y copiará datos directamente de buffer a buffer. En términos de tuberías con nombre frente a sockets, si necesita poder comunicarse potencialmente con diferentes máquinas en el futuro, elija sockets. Si sabe con certeza que nunca tendrá que hacer eso, elija la que le resulte más familiar o más cómoda a sus desarrolladores.
http://msdn.microsoft.com/en-us/library/aa178138(v=sql.80).aspx
Déjame resumir por ti. Si le preocupa el rendimiento, utilice TCP / IP. Pero si tienes una red realmente rápida y no te preocupa el rendimiento, Named Pipes sería "ordenado", ya que podría ahorrarte algo de código.
Sin mencionar, si te apegas a TCP, entonces tendrás algo que se puede escalar, e incluso balancear la carga cuando llegue el momento.
Aclamaciones,