Conceptos avanzados

XenApp y XenDesktop 7.7: Zonas, latencia y rendimiento de intermediación

Zonas

Las implementaciones que abarcan ubicaciones muy dispersas conectadas por una WAN pueden enfrentar problemas de fiabilidad y latencia de red. En lugar de crear varios sitios, cada uno de los cuales requeriría su propia base de datos de sitios de SQL Server que necesitaría administrar por separado, puede configurar zonas dentro de un único sitio.

Impacto de latencia en la intermediación de rendimiento

La mayoría de los usuarios finales enumerarán y lanzarán recursos todos los días. Con la adición de zonas, los usuarios ahora pueden estar en enlaces de mayor latencia siempre y cuando haya un broker local.

Con esta latencia adicional, inevitablemente habrá un impacto en la experiencia del usuario final. Para la mayoría del trabajo que harán los usuarios, verán la lentitud esperada que está vinculada a los viajes de ida y vuelta entre los intermediarios de satélite y la base de datos SQL.

Sin embargo, para lanzar aplicaciones, hay un punto crítico en las sesiones de intermediación. Este punto de problema se debe a la necesidad de elegir el VDA con menor carga en el que lanzar una aplicación. Esto ocurre dentro de una transacción de base de datos y necesita una instantánea de todas las cargas actuales en los VDA dentro del grupo de entrega. Para lograr esto, se toma un bloqueo en todos los trabajadores de un grupo de entrega, lo que impide que otros usuarios (causa la serialización) tomen los mismos bloqueos. También espera y bloquea los cambios de estado del trabajador (como eventos de sesión).

Con baja latencia, el retraso entre tomar los bloqueos y liberarlos es muy pequeño. Sin embargo, a medida que aumenta la latencia, también lo hace el tiempo que se mantienen los bloqueos y, por lo tanto, aumenta el tiempo para las sesiones de broker.

Para respaldar esto, hemos analizado una variedad de latencias y tasas de lanzamiento. Las latencias son los tiempos de ida y vuelta (RTT) y se basan en Estadísticas de latencia de IP de Verizon. Tenga en cuenta que la mayoría de los RTT son inferiores a los valores máximos enumerados, pero queríamos asegurarnos de que estábamos probando con algunos RTT útiles.

Los tiempos de ida y vuelta de 10 milisegundos (ms) cubren la mayoría de los retrasos entre países; 45 ms cubre América del Norte, Europa y Japón; 90 ms cubre el Transatlántico; 160 ms cubre el Transpacífico, América Latina y Asia Pacífico; y 250 ms cubre la EMEA a Asia Pacífico.

Probamos con una variedad de solicitudes concurrentes, cubriendo valores de 12 a 60 en incrementos de 12.

Nota: Las sesiones de VDA se simulan, ya que las pruebas se centran en el impacto de la latencia en el broker. Para esta prueba, hay 57 agentes VDA dentro de un grupo de entrega. Cada prueba intentó iniciar 10 000 usuarios.

Resultados de RTT de 10 ms          
Solicitudes simultáneas 12 24 36 48 60
Tiempos de respuesta medios 0,9 1,4 1,6 2,1 2,6
Solicitudes de intermediación por segundo 14 17,8 22,9 23,2 22,9
Errores (%) 0 0 0 0 0
Tiempo para iniciar 10 000 usuarios 11 min 57 s 9 min 24 s 7 min 16 s 7 min 11 s 7 min 17 s

Como era de esperar, 10 ms es lo suficientemente rápido para manejar las cargas colocadas en el sistema, y no hubo errores. Esta es la forma más rápida de lanzar usuarios. A la velocidad máxima de lanzamiento de 60 usuarios simultáneos, los tiempos de respuesta promedio fueron de 2,6 segundos, tomando 7 minutos y 17 segundos para iniciar los 10 000 usuarios.

Resultados de RTT de 45 ms          
Solicitudes simultáneas 12 24 36 48 60
Tiempos de respuesta medios 1,7 3,1 4,3 6,4 7,3
Solicitudes de intermediación por segundo 7,1 7,8 8,4 7,5 8,2
Errores (%) 0 0 0 0,01 0,01
Tiempo para iniciar 10 000 usuarios 23 min 28 s 21 min 19 s 19 min 51 s 22 min 15 s 20 min 19 s

Con 45 ms, los resultados seguían siendo buenos. A velocidades de lanzamiento muy altas, uno o dos usuarios vieron un error.

Nota: El impacto de la serialización se puede ver en los tiempos de respuesta, con un aumento de 1,7 segundos a 7,3 segundos para hacer de intermediario con una sesión. El tiempo total de intermediación de 10 000 usuarios fue de 20 a 23 minutos.

Resultados de RTT de 90 ms          
Solicitudes simultáneas 12 24 36 48 60
Tiempos de respuesta medios 2,9 6,4 9,5 12,9 16,2
Solicitudes de intermediación por segundo 4,1 3,7 3,8 3,7 3,7
Errores (%) 0 0 0 0,01 0,01
Tiempo para iniciar 10 000 usuarios 40 min 30 s 44 min 29 s 44 min 11 s 44 min 55 s 45 min 04 s

Los resultados de 90 ms registraron pocos errores. Sin embargo, el impacto de las transacciones sobre latencia se hace más evidente, ya que los usuarios ven un tiempo medio aceptable de 2,9 segundos para intermediar una sesión con 12 solicitudes simultáneas, aumentando a 16,2 segundos probablemente inaceptables para intermediar una sesión con 60 solicitudes simultáneas. En este caso, en realidad es más ventajoso para los usuarios de broker a un ritmo más bajo. Tardó entre 40 y 45 minutos en lanzar a los 10 000 usuarios.

Resultados de RTT de 160 ms          
Solicitudes simultáneas 12 24 36 48 60
Tiempos de respuesta medios 5,7 11,4 17,3 23,2 28,0
Solicitudes de intermediación por segundo 2,1 2,1 2,1 2,1 2,1
Errores (%) 0 0 0,12 4,0 17,7
Tiempo para iniciar 10 000 usuarios 1 h 19 min 0 s 1 h 19 min 27 s 1 h 19 min 55 s 1 h 20 min 26 s N/D

Con los 160 ms, comenzamos a ver errores significativos que ocurren con velocidades de lanzamiento más altas, con 4 por ciento de errores en 48 solicitudes y 17,7 por ciento de errores en 60 solicitudes, junto con tiempos de respuesta próximos 30 segundos. Sin embargo, hasta 36 solicitudes, la tasa de error es de 0,1 por ciento con un tiempo promedio de intermediación de 17 segundos.

Nota: Es difícil juzgar el tiempo de lanzamiento de 60 solicitudes, ya que el 17 por ciento de falla es difícil de tener en cuenta.

Con esta latencia, recomendamos no pasar 24 solicitudes simultáneas. Además, el tamaño del Sitio puede ser un factor: El lanzamiento de 1000 usuarios en llevaría unos 8 minutos. Esto ampliaría hasta 1 hora y 20 minutos para 10 000 usuarios. Como tal, no recomendamos un sitio grande con este nivel de latencia a la base de datos.

Resultados de RTT de 250 ms          
Solicitudes simultáneas 12 24 36 48 60
Tiempos de respuesta medios 9,3 15,4 26,7 - -
Solicitudes de intermediación por segundo 1,3 1,6 1,3 - -
Errores (%) 0 0 4,6 42,8 99,0
Tiempo para iniciar 10 000 usuarios 2 h 8 min 33 s 1 h 46 min 52 s 2 h 3 min 46 s N/D N/D

Con una latencia tan alta, se produjo un gran número de tiempos de espera a velocidades de lanzamiento simultáneas más altas. En 48 solicitudes, el 42,8% de las solicitudes falló. En 60 solicitudes, los tiempos de espera eran tan comunes que el sitio no sería utilizable, ya que el 99 por ciento de las solicitudes fallaban. Las únicas tasas de lanzamiento aceptables fueron 12 y 24 solicitudes. Sería difícil recomendar la implementación de un sitio grande con este nivel de latencia: El lanzamiento de 1000 usuarios tomó 13 minutos con 12 solicitudes simultáneas y 11 minutos con 24 solicitudes simultáneas. Tomaría hasta 2 horas y 8 minutos para 10 000 usuarios.

Limitar solicitudes

Si necesita trabajar con una latencia alta y encontrar que se producen demasiados tiempos de espera, se agregó una clave del Registro a XenApp/XenDesktop 7.7 para que pueda manejar solo un número fijo de solicitudes de intermediación simultáneas. StoreFront reintentará las solicitudes por encima del límite después de unos segundos. Esto ayudará a desactivar las solicitudes, reduciendo así la cola de bloqueo. Sin embargo, algunos usuarios pueden terminar viendo tiempos de lanzamiento extendidos, ya que siempre tienen mala suerte y su solicitud siempre está cancelada.

La clave es un DWORD y debe almacenarse en: HKEY_LOCAL_MACHINE\Software\Citrix\DesktopServer\ThrottledRequestAddressMaxConcurrentTransactions

Si la clave no existe, entonces no se establece ningún límite en las solicitudes de intermediación.

Nota: La clave es por Delivery Controller, por lo que las solicitudes totales en SQL Server deben dividirse entre los Controllers remotos.

Resumen

La intermediación funciona sobre la latencia, pero la latencia debe tenerse en cuenta para dimensionar una zona remota. Si una zona es grande, puede ser conveniente mantener una base de datos local a esa zona. Si la zona es pequeña, el uso de una zona remota puede funcionar bien y también reducir los costes de administración sin afectar la experiencia del usuario final.

Recomendamos que sus zonas tengan menos de 250 ms RTT; más allá de eso, debe considerar la posibilidad de configurar diferentes Sitios.

Este artículo ha sido modificado a partir de una entrada de blog escrita por Chris Gilbert. Para leer el blog original y ver los comentarios, vaya a https://www.citrix.com/blogs/2016/02/09/zones-latency-and-brokering-performance-2/.

XenApp y XenDesktop 7.7: Zonas, latencia y rendimiento de intermediación