Estoy utilizando el bus de servicio con nettcprelaybinding. Uno de los lados es el servidor OnPremise que tiene una conexión constante con el bus de servicio. En el otro extremo se encuentra una función web de Azure que responde a las solicitudes web entrantes abriendo el bus de servicio apropiado y obteniendo información del servidor.rendimiento de retransmisión de Servicebus de Azure
Mi preocupación es el rendimiento de la creación del canal. Lleva unos segundos establecer una nueva conexión con el servidor predeterminado a través del bus de servicio. El almacenamiento en caché de mi ChannelFactory no parece ayudar mucho. El rendimiento de la transferencia después de que el canal está abierto es muy bueno.
Cualquier sugerencia sobre cómo mejorar el rendimiento. La información del almacenamiento en caché en Azure solo se puede hacer en cierta medida. Necesito conectarme al servidor predeterminado.
¿Puedo de alguna manera establecer un grupo de conexión para el bus de servicio?
En más, hay una serie de diferentes servidores predeterminados por lo que no es solo una conexión para mantenerse con vida.
Gracias por los buenos comentarios. No sabía sobre el límite de 60 segundos. Si quiero agrupar las conexiones. ¿Cuál es una buena manera de hacer eso? Encontré algo de información siguiendo su enlace (http://code.msdn.microsoft.com/WCF-Azure-NetTCP-Keep-Alive-09f50fd9). Pero, ¿es esta la buena solución en un entorno Azure de múltiples instancias? Si un canal está abierto en una instancia y el siguiente cliente se ejecuta en una instancia diferente? ¿O el equilibrador de carga se asegura de que se use la misma instancia? – user1284390
Según tengo entendido, cada instancia obtiene su propia conexión. Y como los mantienen abiertos, debes tener en cuenta los límites máximos de conexión (2000 o algo así, creo) que están permitidos en un solo espacio de nombres. Si es bueno o malo hacer esto, creo que depende de sus necesidades de rendimiento y escalabilidad. – BrentDaCodeMonkey
Esto es un poco antiguo, pero solo para su información, parece que la mayoría de los LB de Azure ahora están basados en software, y tienen un tiempo de espera predeterminado de 4 minutos (no 1 minuto con los anteriores LB basados en hardware), y esto ahora es configurable. Sin embargo, no está claro para mí, en este momento, si la biblioteca cliente de Service Bus está implementando TCP KeepAlive automáticamente, y por lo tanto un tiempo de espera de LB no es realmente un problema: https://azure.microsoft.com/en-us/blog/new-configurable-idle-timeout-for-azure-load-balanceer/ – Jmoney38