none
Performance de Aplicación de escritorio sobre una conexión IP para base de datos SQL SERVER 2008 EXPRESS RRS feed

  • Pregunta

  • Buenos días,

    Mi consulta está motivada por una reciente decisión del dueño de la empresa para la cual desarrollé un típico sistema administrativo. Se quiere abrir una sucursal en la capital argentina Buenos Aires, la cual deberá poder acceder a la base de datos localizada en el servidor de la Sede en el interior del país mediante una conexión Internet. Para ello solicite que se contrate el servicio con una IP pública y un ancho de banda elevado, que aún no me contestaron a cuando asciende pero actualmente podría decirse que contaríamos con 10 megas promedio o incluso menos. 

    Mi gran duda ya que nunca me tocó tal requerimiento para ningún cliente anterior es si SQL SERVER va a responder bien. Sé que están muy difundidos los Software As a Services, esto es, aplicaciones web, creo que son hoy en día las más idóneas para ello, sin embargo estamos hablando de un sistema de escritorio ya implementado y que está funcionando hace 3 años. No se está pensando en re-desarrollar un sistema nuevo sino adaptar el existente con una conexión remota.

    Sería factible que funcione el esquema que he planteado, aplicación de escritorio desarrollado con visual studio accediendo a un servidor SQL SERVER 2008 EXPRESS remoto con una IP pública estática para el servidor y una velocidad en la sede de 10 mps.

    Cualquier opinión sería de mucha ayuda.

    Gracias.

    miércoles, 29 de julio de 2020 14:57

Respuestas

  • Si, es factible. En principio el SQL Server responde correctamente ante las conexiones remotas por TCP/IP.

    Pero es sensible al tipo de consultas que hace la aplicacion remota. Por ejemplo, si el programa envia un "select … from … where condicion", y la condicion esta bien hecha de forma que solo devuelve una limitada cantidad de informacion para mostrar, entonces eso funcionara bien. Pero si la aplicacion hace un "select * from latabla" sobre una tabla enorme, con lo que se devuelven millones y millones de bytes, con la intencion de luego filtrarlos en lado cliente, pues entonces va a ser lento porque todos esos millones de bytes tienen que viajar por la linea.

    Similarmente, otra cosa que hay que tener en cuenta es la latencia de la linea, que es independiente del ancho de banda. Por ejemplo, si tu linea tiene una latencia de 200 milisegundos, entonces cuando la aplicacion cliente envie una consulta al servidor se tardara al menos 400 milisegundos en recibir la respuesta (200 de ida y 200 de vuelta), mas lo que tarde el servidor en resolver la consulta, mas lo que se tarde en transmitir los bytes de ida y de vuelta (esto ultimo si depende de la velocidad de la linea). Esto es aceptable si la aplicacion cliente envia una sola consulta y muestra los resultados. Pero si esta escrita de forma que cada vez que require algo lo hace en varios viajes, entonces se va a volver muy lenta. Por ejemplo, si hay que grabar los datos de un grid y envia un Insert por cada linea, en lugar de juntar todos los Insert en un lote y enviarlos de golpe, entonces va a ser muy lenta si la latencia es grande. Aqui es donde se nota como de bien hecha esta la aplicacion. Si los desarrolladores tuvieron en cuenta estas cosas (agrupar las sentencias en lotes en lugar de enviarlas individualmente, fltrar datos en lado servidor y no en lado cliente, etc.) entonces se va a notar que funciona mucho mejor cuando esta en remoto. Si no se molestaron en optimizar estas cosas porque, total, en la red local no se nota, pues entonces funcionara mucho peor.

    miércoles, 29 de julio de 2020 15:53

Todas las respuestas

  • Si, es factible. En principio el SQL Server responde correctamente ante las conexiones remotas por TCP/IP.

    Pero es sensible al tipo de consultas que hace la aplicacion remota. Por ejemplo, si el programa envia un "select … from … where condicion", y la condicion esta bien hecha de forma que solo devuelve una limitada cantidad de informacion para mostrar, entonces eso funcionara bien. Pero si la aplicacion hace un "select * from latabla" sobre una tabla enorme, con lo que se devuelven millones y millones de bytes, con la intencion de luego filtrarlos en lado cliente, pues entonces va a ser lento porque todos esos millones de bytes tienen que viajar por la linea.

    Similarmente, otra cosa que hay que tener en cuenta es la latencia de la linea, que es independiente del ancho de banda. Por ejemplo, si tu linea tiene una latencia de 200 milisegundos, entonces cuando la aplicacion cliente envie una consulta al servidor se tardara al menos 400 milisegundos en recibir la respuesta (200 de ida y 200 de vuelta), mas lo que tarde el servidor en resolver la consulta, mas lo que se tarde en transmitir los bytes de ida y de vuelta (esto ultimo si depende de la velocidad de la linea). Esto es aceptable si la aplicacion cliente envia una sola consulta y muestra los resultados. Pero si esta escrita de forma que cada vez que require algo lo hace en varios viajes, entonces se va a volver muy lenta. Por ejemplo, si hay que grabar los datos de un grid y envia un Insert por cada linea, en lugar de juntar todos los Insert en un lote y enviarlos de golpe, entonces va a ser muy lenta si la latencia es grande. Aqui es donde se nota como de bien hecha esta la aplicacion. Si los desarrolladores tuvieron en cuenta estas cosas (agrupar las sentencias en lotes en lugar de enviarlas individualmente, fltrar datos en lado servidor y no en lado cliente, etc.) entonces se va a notar que funciona mucho mejor cuando esta en remoto. Si no se molestaron en optimizar estas cosas porque, total, en la red local no se nota, pues entonces funcionara mucho peor.

    miércoles, 29 de julio de 2020 15:53
  • Hola

    Veo que ya tienes una respuesta a tu pregunta. Si tienes otra consulta no dudes en abrir otro hilo.

    Saludos!

    miércoles, 29 de julio de 2020 20:46
    Moderador