Conceptos avanzados

XenApp y XenDesktop 7.11 hasta el actual: Mejoras en las consultas de latencia y bloqueo de SQL

En el artículo XenApp y XenDesktop 7.7: Zonas, latencia y rendimiento de intermediación se proporciona información sobre el rendimiento para la intermediación con latencia. En este artículo se describen las mejoras para la intermediación con latencia de XenApp y XenDesktop 7.11. También describe mejoras para evitar el interbloqueo en el registro de VDA.

Intermediación con mejoras de latencia

En XenApp y XenDesktop 7.11, revisamos el código SQL principal de intermediación que determina qué VDA es el menos cargado y, a continuación, envía una solicitud de inicio a ese VDA. Decidimos cambiar de un algoritmo de equilibrio de carga “perfecto” a un algoritmo de equilibrio de carga “lo suficientemente bueno”.

Antes de XenApp y XenDesktop 7.11, el código buscaba el VDA menos cargado y bloqueaba o bloqueaba otras solicitudes de inicio hasta que ese VDA estuviera disponible. Esto bloqueó todas las demás solicitudes de intermediación.

Desde XenApp y XenDesktop 7.11, el código busca el trabajador menos cargado que no esté bloqueado actualmente. Esto significa que, aunque es posible que no tengamos al trabajador menos cargado (tal vez solo tengamos el segundo o el tercero menos cargado), podemos hacerlo sin bloquear todas las demás solicitudes de lanzamiento. Si no podemos encontrar a un trabajador desbloqueado, nos sentamos y esperamos las cerraduras. Con suficientes VDA, es raro encontrar todos ellos bloqueados al mismo tiempo, pero cuando ocurre el comportamiento es el mismo que con el algoritmo anterior.

En algunos casos, los administradores pueden notar una ligera diferencia en el equilibrio de carga, pero necesita mucha atención para notar que no usamos el VDA menos cargado.

Hay otras ubicaciones en el código de intermediación central donde se han mejorado los problemas de bloqueo de SQL. Citrix recomienda que los sitios grandes utilicen un broker de CU3 7.13 o 7.6 para tener todas las mejoras conocidas actualmente.

Resultados del desempeño

La tabla siguiente agrega dos puntos de datos a los datos en el artículo anteriorpara mostrar la intermediación resultante con mejoras de latencia:

Versión del producto 7.7 7.11+ 7.7 7.7 7.11+
Latencia (ms) 90 90 250 250 250
Solicitudes Simultáneas 48 48 36 48 48
Tiempo (s) medio (s) de respuesta 12,9 3,7 26,7 N/D 7,6
Solicitudes de intermediación por segundo 3,7 12,6 1,3 N/D 6,3
Errores (%) 0 0 4,6 42,8 0
Tiempo para iniciar 10 000 usuarios 44 minutos 55 s 13 minutos 10 s 2 horas 03 minutos n/d 26 minutos 27 s

Como puede ver con 250 ms de latencia, XenApp y XenDesktop 7.11 ahora superan el código 7.7 a 90 ms. Por lo tanto, en lugar de pasar tiempo probando muchos puntos de datos, probamos uno que falló anteriormente. Puede ver que, con 7.11 o posterior, los usuarios experimentan una intermediación más rápida de recursos, incluso con latencia entre un broker y el servidor SQL.

Los clientes de los controladores LTSR 7.6 CU3 también se benefician de las mismas mejoras. Aunque no esperamos que LTSR 7.6 CU3 se implemente con latencia, estos cambios mejoran el rendimiento incluso sin latencia, y sabemos que algunos clientes tienen LTSR 7.6 CU3 con cierta latencia.

Serializaciones de tormentas de registro

Desafortunadamente, un área que sabemos que hay una cerradura es el registro de VDA. La razón del bloqueo es evitar bloqueos al registrar trabajadores. Ahora tenemos una comprensión mucho mejor de la causa de los interbloqueos, que se debió a no bloquear sesiones para un trabajador en un orden consistente sobre múltiples procesos de registro. Ahora hacemos el bloqueo de sesión por ID de sesión, que detiene el interbloqueo de registros de VDA.

Hemos probado este cambio de comportamiento internamente y hemos descubierto que ayudó a resolver algunos problemas en nuestras pruebas de la escala del nuevo registro. Sin embargo, debido a que algunos clientes tienen entornos muy complejos, no hemos eliminado este bloqueo por completo, para dar tiempo para más pruebas. En su lugar, hemos proporcionado un ajuste sobre el uso de este bloqueo para clientes con XenApp y XenDesktop 7.12 o posterior. Este ajuste se encuentra en la tabla CHB_Config.Site de la base de datos XenApp y XenDesktop 7.12:

    select SerializeMultiSessionAudits, SerializeMultiSessionDeregistrations from chb_config.Site

    SerializeMultiSessionAudits SerializeMultiSessionDeregistrations

    --------------------------- ------------------------------------

    1 1

Puede establecer estos indicadores en 0 para eliminar el uso del bloqueo:

    update chb_config.Site set SerializeMultiSessionAudits=0, SerializeMultiSessionDeregistrations=0

    select SerializeMultiSessionAudits, SerializeMultiSessionDeregistrations from chb_config.Site

    (1 row(s) affected)

    SerializeMultiSessionAudits SerializeMultiSessionDeregistrations

    --------------------------- ------------------------------------

    0 0

Dado que XenApp y XenDesktop 7.15, el bloqueo predeterminado es que se inhabilite. Al actualizar también a XenApp y XenDesktop 7.15 o posterior, también se inhabilita el bloqueo. El ajuste se proporciona para los clientes que necesitan volver a habilitar el bloqueo.

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/2017/03/06/latency-and-sql-blocking-query-improvements/.

XenApp y XenDesktop 7.11 hasta el actual: Mejoras en las consultas de latencia y bloqueo de SQL