Por qué una aplicación SQL parlanchina se arrastra por una VPN y qué conviene agrupar

Un formulario que en una red local aparece en menos de un segundo tarda cinco segundos por una VPN, mientras que una copia de archivo por el mismo enlace va a plena velocidad. La diferencia no es el ancho de banda. El formulario espera una secuencia de respuestas y paga el viaje completo en cada paso, mientras que la copia de archivo mantiene los bytes en movimiento de forma continua. Cuente esas esperas antes de tocar la línea de acceso.

El síntoma es una pantalla, no una consulta

Cada consulta de esa pantalla puede ser rápida y la pantalla puede seguir siendo lenta, porque el total es la suma de esperas y no la suma de tiempos de ejecución. Una sentencia que se ejecuta en dos milisegundos sigue costando un viaje completo cuando el cliente debe recibir su resultado antes de enviar la siguiente. En un camino con cuarenta milisegundos de latencia, cien llamadas dependientes suman unos cuatro segundos antes de que empiece cualquier trabajo de renderizado. Esa aritmética es un modelo de la espera, no una medición de su enlace.

Por eso una prueba de velocidad parece inocente. La transferencia masiva mide el caudal, un formulario parlanchín mide la latencia, y una VPN puede ser excelente en lo uno y corriente en lo otro. Diagnosticar la pantalla significa, por tanto, medir la pantalla y no el enlace.

Registre el tiempo de extremo a extremo de una acción de usuario antes de cambiar nada. Ese número es la única línea base que puede decirle si una corrección posterior funcionó.

Cuente las esperas secuenciales en una acción de usuario

Instrumente el cliente en lugar de adivinar. En psql, \timing on imprime el tiempo transcurrido de cada sentencia, y EXPLAIN (ANALYZE, BUFFERS) muestra cuánto de ese tiempo pasó realmente el servidor en el trabajo.

La diferencia entre esos dos números es su sobrecarga de red y de cliente. Si una sentencia se ejecuta en dos milisegundos y el cliente registra sesenta, los cincuenta y ocho restantes son viaje y procesamiento local, y ningún índice los eliminará. Repita esa comparación para cada sentencia que emite la pantalla y sume las diferencias en lugar de los tiempos de ejecución.

Anote el resultado como un recuento de esperas secuenciales. Esa es la magnitud que las dos secciones siguientes pueden reducir, y es un número sobre el que puede discutir con pruebas.

Agrupe las llamadas independientes y conserve las dependientes

Dos sentencias que no leen los resultados de la otra pueden viajar juntas y recogerse una sola vez, lo que convierte dos esperas en una. Dos sentencias en las que la segunda necesita el valor de la primera no pueden, porque la dependencia es real y agruparlas cambiaría lo que hace el programa. Separe las llamadas en esos dos montones antes de reescribir nada, y el tamaño de cada montón le dice qué es posible.

El trabajo basado en conjuntos elimina esperas de forma más completa que la agrupación. Una consulta que devuelve las filas que un bucle iba trayendo de una en una elimina el bucle y también los viajes. Busque primero el bucle, porque suele ser la mayor ganancia y el cambio más fácil de revisar.

Una agrupación debe seguir conservando el tratamiento de errores y los límites de transacción. Concatenar sentencias no relacionadas en una sola cadena no es una optimización segura, y una agrupación que esconde una sentencia fallida detrás de un envío correcto es peor que las esperas que ahorró.

Reutilice las conexiones antes de comprar ancho de banda

Una conexión nueva cuesta resolución de nombres, un handshake TCP, negociación TLS y autenticación, y en un camino de alta latencia cada uno de ellos es otro viaje antes de que se ejecute la primera consulta. Los grupos de conexiones existen para pagar ese costo una vez por proceso y no una vez por llamada.

En ADO.NET, cerrar o desechar una conexión agrupada la devuelve para reutilizarla en lugar de abrir una nueva física, así que el patrón que parece una fuga suele ser el uso correcto. Verifique que el grupo se esté usando de verdad en lugar de suponerlo: registre la creación de conexiones físicas u observe el número de sesiones en el servidor mientras la pantalla funciona. La guía de rendimiento de SQL dice lo mismo sobre reducir viajes y agrupar las llamadas ad hoc frecuentes, con ejemplos específicos del servicio que usted debería trasladar a su propio despliegue.

La agrupación elimina el costo de configuración y deja intactas las esperas secuenciales de las consultas. Es un requisito previo para una medición limpia, no una corrección por sí sola.

Valore mover la ejecución más cerca de los datos

Ejecutar la aplicación cerca de la base de datos sustituye muchos intercambios remotos con la base por una sola sesión remota de pantalla. Para una carga parlanchina puede ser un cambio grande, y es un cambio operativo tanto como un cambio de rendimiento: la gestión de sesiones, el control de acceso, el despliegue de software y la experiencia de usuario se mueven todos con la aplicación.

Mida la interfaz real y los datos que transfiere antes de suponer que cualquier dirección es más rápida. Una sesión de escritorio remoto mueve píxeles, y una pantalla con gráficos densos puede rendir peor por el mismo camino que las consultas que sustituyó, sobre todo cuando el cliente redibuja continuamente.

Después repita la acción original y compare tres números: esperas secuenciales, volumen de resultados y tiempo de finalización de extremo a extremo. Una mejora que cambia la tarea de usuario medida y a la vez preserva la corrección de los datos y la política de acceso es la que merece conservarse.