Por que unha aplicación SQL falangueira se arrastra por unha VPN e que convén agrupar

Un formulario que nunha rede local aparece en menos dun segundo tarda cinco segundos por unha VPN, mentres que unha copia de ficheiro polo mesmo enlace vai a plena velocidade. A diferenza non é o ancho de banda. O formulario espera unha secuencia de respostas e paga a viaxe completa en cada paso, mentres que a copia de ficheiro mantén os bytes en movemento de forma continua. Conta esas esperas antes de tocar a liña de acceso.

O síntoma é unha pantalla, non unha consulta

Cada consulta desa pantalla pode ser rápida e a pantalla pode seguir sendo lenta, porque o total é a suma de esperas e non a suma de tempos de execución. Unha sentenza que se executa en dous milisegundos segue costando unha viaxe completa cando o cliente debe recibir o seu resultado antes de enviar a seguinte. Nun camiño con corenta milisegundos de latencia, cen chamadas dependentes suman uns catro segundos antes de que comece calquera traballo de renderizado. Esta aritmética é un modelo da espera, non unha medición do teu enlace.

Por iso unha proba de velocidade parece inocente. A transferencia masiva mide o caudal, un formulario falangueiro mide a latencia, e unha VPN pode ser excelente nunha cousa e corrente na outra. Diagnosticar a pantalla significa, xa que logo, medir a pantalla e non o enlace.

Rexistra o tempo de extremo a extremo dunha acción de usuario antes de cambiar nada. Ese número é a única liña base que pode dicirche se unha corrección posterior funcionou.

Conta as esperas secuenciais nunha acción de usuario

Instrumenta o cliente en lugar de adiviñar. En psql, \timing on imprime o tempo transcorrido de cada sentenza, e EXPLAIN (ANALYZE, BUFFERS) mostra canto dese tempo pasou realmente o servidor no traballo.

A diferenza entre eses dous números é a túa sobrecarga de rede e de cliente. Se unha sentenza se executa en dous milisegundos e o cliente rexistra sesenta, os cincuenta e oito restantes son viaxe e procesamento local, e ningún índice os eliminará. Repite esa comparación para cada sentenza que emite a pantalla e suma as diferenzas en lugar dos tempos de execución.

Anota o resultado como un reconto de esperas secuenciais. Esa é a magnitude que as dúas seccións seguintes poden reducir, e é un número sobre o que podes discutir con probas.

Agrupa as chamadas independentes, conserva as dependentes

Dúas sentenzas que non len os resultados da outra poden viaxar xuntas e recollerse unha soa vez, o que converte dúas esperas nunha. Dúas sentenzas nas que a segunda necesita o valor da primeira non poden, porque a dependencia é real e agrupalas cambiaría o que fai o programa. Separa as chamadas neses dous montóns antes de reescribir nada, e o tamaño de cada montón diche que é posible.

O traballo baseado en conxuntos elimina esperas de forma máis completa que a agrupación. Unha consulta que devolve as ringleiras que un bucle ía traendo dunha en unha elimina o bucle e tamén as viaxes. Busca primeiro o bucle, porque adoita ser a maior ganancia e o cambio máis doado de revisar.

Unha agrupación debe seguir conservando o tratamento de erros e os límites de transacción. Concatenar sentenzas sen relación nunha soa cadea non é unha optimización segura, e unha agrupación que esconde unha sentenza fallida detrás dun envío correcto é peor que as esperas que aforrou.

Reutiliza as conexións antes de comprar ancho de banda

Unha conexión nova custa resolución de nomes, un handshake TCP, negociación TLS e autenticación, e nun camiño de alta latencia cada un deles é outra viaxe antes de que se execute a primeira consulta. Os grupos de conexións existen para pagar ese custo unha vez por proceso e non unha vez por chamada.

En ADO.NET, pechar ou desbotar unha conexión agrupada devólvea para reutilizala en lugar de abrir unha nova física, así que o patrón que parece unha fuga adoita ser o uso correcto. Verifica que o grupo se está usando de verdade en lugar de supoñelo: rexistra a creación de conexións físicas ou observa o número de sesións no servidor mentres a pantalla funciona. As pautas de rendemento de SQL din o mesmo sobre reducir viaxes e agrupar as chamadas ad hoc frecuentes, con exemplos específicos do servizo que deberías trasladar ao teu propio despregamento.

A agrupación elimina o custo de configuración e deixa intactas as esperas secuenciais das consultas. É un requisito previo para unha medición limpa, non unha corrección por si soa.

Valora mover a execución máis preto dos datos

Executar a aplicación preto da base de datos substitúe moitos intercambios remotos coa base por unha soa sesión remota de pantalla. Para unha carga falangueira pode ser un cambio grande, e é un cambio operativo tanto como un cambio de rendemento: a xestión de sesións, o control de acceso, o despregamento de software e a experiencia de usuario móvense todos coa aplicación.

Mide a interface real e os datos que transfire antes de supor que calquera dirección é máis rápida. Unha sesión de escritorio remoto move píxeles, e unha pantalla con gráficos densos pode render peor polo mesmo camiño que as consultas que substituíu, sobre todo cando o cliente redeseña continuamente.

Despois repite a acción orixinal e compara tres números: esperas secuenciais, volume de resultados e tempo de finalización de extremo a extremo. Unha mellora que cambia a tarefa de usuario medida e á vez preserva a corrección dos datos e a política de acceso é a que merece conservarse.