Tree permite conexiones remotas a través de VPN sin necesidad de usar servicios de escritorio remoto (que suponen un coste y requieren normalmente un servidor adicional o robarle recursos al principal).
La velocidad remota por VPN depende de varios factores:
- La complejidad de las consultas SQL
- La velocidad del servidor SQL
- La velocidad de la línea y latencia en la ubicación del servidor
- La velocidad de la línea y latencia en la ubicación remota
- La calidad y velocidad de la VPN
En realidad, las dos primeras no dependen de si estamos en remoto o en la LAN.
Es imposible mediante software (TREE) corregir las deficiencias de los 4 últimos puntos.
Para evaluar la calidad de los puntos 1 y 2, basta con abrir el Management Studio de SQL Server en local, y lanzar una de las consultas que requieren demasiado tiempo. Como el punto 1 sólo se puede tocar desde la propia programación de TREE (siempre es mejorable, pero está muy optimizada), podemos decir que: En una LAN, TREE es tan rápido como sea vuestro servidor SQL.
Si TREE no va rápido en la LAN, es necesario invertir en un servidor SQL más moderno, con más RAM (SQL Server es un gran consumidor de RAM y le gusta tener las bases de datos completas en memoria para correr). O bien, ver si no está optimizado y bien mantenido.
Pero si estás leyendo este artículo, seguramente TREE va bien en local, pero va lento en remoto.
Para evaluar la calidad de los puntos 3,4,5 se puede hacer lo mismo que hemos hecho antes (lanzar esa consulta lenta), pero desde un Management Studio instalado en el equipo remoto, y comparar los tiempos con los obtenidos en local.
En realidad, TREE usa componentes nativos para realizar la conexión SQL, con lo que no es necesario instalar un Management Studio para hacer las pruebas, pero por otra parte me gusta que las pruebas se realicen desde fuera de TREE para que el usuario pueda ver que las consultas no dependen de TREE. Por tanto, puedes usar el entorno de pruebas que más te guste: Gestor de sentencias SQL de TREE, SqlServer Management Studio.
Si vemos que los tiempos en local y remotos son muy distintos, sabemos que tenemos que mejorar los puntos 3, 4 y 5.
Los puntos 3 y 4 son muy fáciles de comprobar realizando un test de velocidad de la línea. Si le velocidad es baja o la latencia alta, asúmelo, desde Tree todavía no hacemos milagros. Es necesario que mejores esas conexiones.
El punto 5 no es tan fácil de comprobar ya que se requieren utilidades. Por ejemplo podemos usar un simple PING o copiar archivos grandes y medir los tiempos, o bien utilidades como jperf.
Si el resultado no responde al que debería según la calidad de las conexiones (puntos 3 y 4) responde a esta pregunta ¿te has gastado menos de 2000€ en tu firewall?. Si la respuesta es sí, tu firewall puede no estar a la altura y que tengas en ese punto el cuello de botella. Lógicamente, tu firewall debe estar dimensionado para admitir un número concreto de conexiones remotas a una velocidad adecuada. A mi me gusta la familia de firewalls de Sonicwall, pero sé que Fortinet por ejemplo también tiene filrewalls de calidad.
Antes de invertir en un nuevo firewall, asesórate por un experto en el tema.
En general, busca a un experto en redes y SQL que te indique los cuellos de botella. Este artículo no deja de ser un resumen para poder realizar una primera evaluación rápida y saber por dónde buscar.