none
Algunas consultas sobre redes. Aclárenme estas dudas por favor. RRS feed

  • Pregunta

  • Ojalá que el foro elegido se ajuste a la pregunta.

    Verán, desarrollé un software tipo Windows Form en VB.Net con base de datos de SQL Server. La base de datos es relativamente pequeña, no supera los cincuenta mil registros y con las filas asociadas a cada una puede llegar a no más de doscientos mil.

    El programa funciona así: En una máquina con Windows 10, que hace las veces de servidor, está instalado SQL Server y allí mismo alberga la base de datos. A esa base se accede desde el programa instalado en esa misma máquina y de otras cinco máquinas cliente que también tienen instalado Windows 10.

    El caso es que el programa funciona, pero con el uso diario se nota que se produce un cierto retardo al acceder desde los equipos cliente (unos 3 a 5 segundos) y desde el equipo principal el acceso es casi instantáneo. 

    NOTA: El acceso lo realiza vía red  (cable o Wi-Fi) y el retardo es casi similar.

    Las consultas que tengo son las siguientes:

    1º ¿Qué me sugieren para mejorar la velocidad de acceso para que sea imperceptible el retardo?

    2º Tengo entendido que existen servidores dedicados ¿instalando SQL Server en un servidor dedicado el acceso a los datos sería más rápido? ¿sería notoria la diferencia? ¿Funcionaría con SLQ Server Standar? ¿o requiere una versión especial de SQL Server?

    3º ¿La velocidad de acceso depende también de las características de las máquinas cliente?

    Cualquier sugerencia es bienvenida.


    • Editado James2016-2 viernes, 22 de enero de 2021 20:01
    viernes, 22 de enero de 2021 20:01

Respuestas

  • 1.- Puesto que es muy rápido en local y lento desde la red, cabe inferir que el problema es debido al volumen de información transferido por la red, aunque esto convendría que lo comprobases usando alguna herramienta para monitorizar el tráfico de red. Si es así, y suponiendo que no sea posible incrementar la velocidad de la red, entonces lo que hay que hacer es cuidar el programa para que se minimice el tráfico de red. Por ejemplo, no se deben traer los cincuenta mil registros a un dataset y luego filtrarlos en lado cliente, sino que se debe enviar una consulta ya filtrada con un "where" que recupere la mínima cantidad de información necesaria en cada caso. Otra precaución es agrupar las sentencias de forma que se produzca la mínima cantidad de "viajes" por la red, por ejemplo, si hay que insertar mil registros no enviar mil comandos insert, sino un solo insert con mil entradas en "values". Similarmente, no usar un bucle que envíe "select", sino usar un "join" para recuperarlo todo de una vez.

    2.- No, si el problema está en el tráfico de red, un servidor dedicado no mejorará nada. Únicamente si el problema está en una sobrecarga de la máquina en la que se encuentra el SQL Server es cuando convendría trasladarlo a un servidor dedicado. Y sí, la versión Standard debería ser más que suficiente para soportar cinco puestos.

    3.- La velocidad de acceso debería depender muy poco de las características de las máquinas cliente, si es que el programa está bien escrito (enviando consultas correctas para que el trabajo de acceso a datos se haga en el servidor). Pero si por ejemplo el programa trae todos los datos a un dataset y luego lo filtra en lado cliente, entonces sí que se notarán mucho las prestaciones de la máquina cliente.

    • Marcado como respuesta James2016-2 viernes, 22 de enero de 2021 23:55
    viernes, 22 de enero de 2021 22:43

Todas las respuestas

  • 1.- Puesto que es muy rápido en local y lento desde la red, cabe inferir que el problema es debido al volumen de información transferido por la red, aunque esto convendría que lo comprobases usando alguna herramienta para monitorizar el tráfico de red. Si es así, y suponiendo que no sea posible incrementar la velocidad de la red, entonces lo que hay que hacer es cuidar el programa para que se minimice el tráfico de red. Por ejemplo, no se deben traer los cincuenta mil registros a un dataset y luego filtrarlos en lado cliente, sino que se debe enviar una consulta ya filtrada con un "where" que recupere la mínima cantidad de información necesaria en cada caso. Otra precaución es agrupar las sentencias de forma que se produzca la mínima cantidad de "viajes" por la red, por ejemplo, si hay que insertar mil registros no enviar mil comandos insert, sino un solo insert con mil entradas en "values". Similarmente, no usar un bucle que envíe "select", sino usar un "join" para recuperarlo todo de una vez.

    2.- No, si el problema está en el tráfico de red, un servidor dedicado no mejorará nada. Únicamente si el problema está en una sobrecarga de la máquina en la que se encuentra el SQL Server es cuando convendría trasladarlo a un servidor dedicado. Y sí, la versión Standard debería ser más que suficiente para soportar cinco puestos.

    3.- La velocidad de acceso debería depender muy poco de las características de las máquinas cliente, si es que el programa está bien escrito (enviando consultas correctas para que el trabajo de acceso a datos se haga en el servidor). Pero si por ejemplo el programa trae todos los datos a un dataset y luego lo filtra en lado cliente, entonces sí que se notarán mucho las prestaciones de la máquina cliente.

    • Marcado como respuesta James2016-2 viernes, 22 de enero de 2021 23:55
    viernes, 22 de enero de 2021 22:43
  • 1.- Puesto que es muy rápido en local y lento desde la red, cabe inferir que el problema es debido al volumen de información transferido por la red, aunque esto convendría que lo comprobases usando alguna herramienta para monitorizar el tráfico de red. Si es así, y suponiendo que no sea posible incrementar la velocidad de la red, entonces lo que hay que hacer es cuidar el programa para que se minimice el tráfico de red. Por ejemplo, no se deben traer los cincuenta mil registros a un dataset y luego filtrarlos en lado cliente, sino que se debe enviar una consulta ya filtrada con un "where" que recupere la mínima cantidad de información necesaria en cada caso. Otra precaución es agrupar las sentencias de forma que se produzca la mínima cantidad de "viajes" por la red, por ejemplo, si hay que insertar mil registros no enviar mil comandos insert, sino un solo insert con mil entradas en "values". Similarmente, no usar un bucle que envíe "select", sino usar un "join" para recuperarlo todo de una vez.

    2.- No, si el problema está en el tráfico de red, un servidor dedicado no mejorará nada. Únicamente si el problema está en una sobrecarga de la máquina en la que se encuentra el SQL Server es cuando convendría trasladarlo a un servidor dedicado. Y sí, la versión Standard debería ser más que suficiente para soportar cinco puestos.

    3.- La velocidad de acceso debería depender muy poco de las características de las máquinas cliente, si es que el programa está bien escrito (enviando consultas correctas para que el trabajo de acceso a datos se haga en el servidor). Pero si por ejemplo el programa trae todos los datos a un dataset y luego lo filtra en lado cliente, entonces sí que se notarán mucho las prestaciones de la máquina cliente.

    Gracias, voy a verificar los comandos a ver que es lo que produce mayor ralentización.
    viernes, 22 de enero de 2021 23:55
  • Una sugerencia que yo te haría es que en, al menos el equipo servidor, el equipo sea lo suficientemente veloz para funcionar como tal.

    Es decir:

    • Una memoria ram de al menos 16gb
    • Un disco duro de estado sólido SSD

    En sí no depende tanto de la velocidad del internet, ya que si trabajas en red local y no por remotos, entonces el problema es el rendimiento de tu equipo servidor; en mi caso tengo mis servidores virtualizados y así los puedo administrar mejor, si el servidor se satura el retardo depende directamente de el, no de la velocidad del internet, puedes hacer una prueba dejando solamente un equipo conectado directamente al servidor para que corrobores que, posiblemente al inicio te va a funcionar sin problemas, pero a medida que vayan colgándose más usuarios, éste se va a ir alentando poco a poco.

    Intenta haciendo pruebas de rendimiento del equipo servidor conectando de 1 a 1 equipos y comprobar si el rendimiento va disminuyendo conforme se conectan tus equipos clientes al equipo servidor.

    • Marcado como respuesta James2016-2 domingo, 24 de enero de 2021 23:05
    • Desmarcado como respuesta James2016-2 domingo, 24 de enero de 2021 23:06
    sábado, 23 de enero de 2021 15:19
  • [...] si el servidor se satura el retardo depende directamente de el [...]

    Sí, pero fíjate en esta frase en la pregunta original:

    con el uso diario se nota que se produce un cierto retardo al acceder desde los equipos cliente (unos 3 a 5 segundos) y desde el equipo principal el acceso es casi instantáneo

    En particular la observación es que a pesar de tener conectados varios equipos cliente, donde funciona con lentitud, en el equipo principal el acceso es casi instantáneo. Eso indicaría que el servidor de base de datos NO está saturado, porque si lo estuviera también afectaría al equipo principal.

    sábado, 23 de enero de 2021 18:36