Conceptos avanzados

XenApp y XenDesktop 7.11 hasta la actual: mejoras en las consultas de bloqueo de SQL y latencia

La información de rendimiento para la intermediación con latencia se proporciona en el artículo XenApp and XenDesktop 7.7: Zones, Latency, and Brokering Performance. En este artículo se describen las mejoras para la intermediación con latencia de XenApp y XenDesktop 7.11. También describe las mejoras para evitar bloqueos en el registro del 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, enviamos una solicitud de lanzamiento 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 lanzamiento 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 el trabajador menos cargado (quizás solo tengamos el segundo o el tercero menos cargado), podemos hacerlo sin bloquear todas las demás solicitudes de lanzamiento. Si no podemos encontrar un trabajador sin llave, nos sentamos y esperamos las cerraduras. Con suficientes VDA, es raro encontrarlos todos bloqueados al mismo tiempo, pero cuando ocurre el comportamiento es el mismo que en 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 usen un agente CU3 de 7.13 o 7.6 para obtener todas las mejoras conocidas actualmente.

Resultados de rendimiento

La siguiente tabla agrega dos puntos de datos a los datos del artículo anterior para 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) de respuesta promedio 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 min 10 s 2 h 03 min n/d 26 min 27 s

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

Los clientes de 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 siguen mejorando el rendimiento incluso sin latencia, y sabemos que algunos clientes sí tienen LTSR 7.6 CU3 con cierta latencia.

Serializaciones de tormentas de registro

Desafortunadamente, un área en la que sabemos que hay un bloqueo es el registro de VDA. El motivo del bloqueo es evitar bloqueos al registrar a los 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, lo que detiene el bloqueo 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 a más pruebas. En su lugar, hemos proporcionado un ajuste sobre el uso de este bloqueo para los clientes con XenApp y XenDesktop 7.12 o posterior. Este ajuste se encuentra en la tabla CHB_Config.site de la base de datos de 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 candado:

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 sintonizable se proporciona para los clientes que necesitan volver a activar el bloqueo.

Este artículo ha sido modificado de una publicación 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 la actual: mejoras en las consultas de bloqueo de SQL y latencia