none
Velocidad adecuada para establecer una conexión a través de internet. RRS feed

  • Pregunta

  • Estimados, acabo de llegar del mundo Access y he convertido una base de datos considerable que, aunque no tiene muchas megas, unos 30Mb, si que tiene muuuuuchas tablas unas 110 mas o menos y muchiiiisimos registros, a SQL Server 2012 Express. Me surgen algunas dudas y voy a contrarreloj pues debo tenerlo todo montado y funcionando esta semana.

    En mi contra diré que no tengo ni idea de SQL Server y buscando por la red he conseguido la información básica para instalar en el servidor el SQL Server 2012 Express, importar las tablas de Access, crear lo índices y relaciones (Esquemas), y crear los usuarios para que el front-end que sigue estando en Access 2010 se conecte al servidor a traves de ODBC. El acceso se hará de dos formas, bien por intranet o bien por Internet.

    Tras esta introducción daré mas detalles, el SQL server lo he instalado en una maquina potente que actua de servidor, con un windows 2008 Server. He abierto los puertos correspondientes y dado permisos al firewall hasta ahí todo bien puesto que puedo conectarme a la base de datos desde dentro de la red y desde Internet. La línea ADSL que se dispone es de 5 Mb de bajada reales y 500 kb subida reales, medido con un test de velocidad.

    El front-end ejecutándolo desde dentro de la misma red va estupendamente, se abren los formularios rápidamente, por poner un ejemplo, abro un formulario que se usa a modo de búsqueda de registros y tiene un subformulario que carga 7200 registros, provenientes de una consulta donde intervienen cinco tablas y donde un par de campos son calculados. Ese formulario, como decía, abriéndolo por intranet funciona perfectamente, la carga es ipsofacta, se puede trabajar bien.

    El problema lo tengo cuando el mismo formulario lo abro a través de Internet, la carga de los registros se hace tan eterna que es imposible trabajar con la aplicación, cuando digo que es eterna perfectamente me puede tardar mas de cinco minutos reales en abrir dicho formulario. Sin embargo, formularios simples que solo leen de una tabla los carga bien, apreciando un pequeño retardo pero casi inapreciable, dando por echo de que los datos viajan a través del ADSL.

    Volviendo al ejemplo, aproximadamente los megas que podrían ocupar esos 7200 registros no llega a los 600kb por lo que entiendo que SQL debería de servirlos a Access en cuestión de un segundo, mas o menos.

    He buscado por Internet sin obtener un resultado satisfactorio algún dato que me oriente sobre la velocidad adecuada del ADSL para poder manejar el volumen de datos que tengo entre manos pero no encuentro dato alguno, además ahora dudo de si el problema es por el ADSL o por la construcción de las consultas que en algún punto se le empalaguen, bien al SQL Server o bien a Access.

    A mi favor diré que hasta ahora, esa base de datos, lleva trabajando unos ocho años exclusivamente en Access, tanto el back-end como el front-end, a la que se suelen conectar simultáneamente unos cinco equipos en intranet y hasta ahora, jamás he tenido problemas alguno de rendimiento, incluso ahora, estando las tablas en el servidor SQL, los mismos equipos en Intranet siguen conectándose sin mayor problema, solo cuando accedo desde Internet se hace insufrible manejarla.

    Después del testamento que os acabo de poner se os ocurre algún motivo por lo que me funcione así? ¿alguna sugerencia sobre por donde debería investigar? Igual algo no he configurado bien en el servidor SQL o en la configuración del Driver ODBC?

    Al respecto de esto último, Driver ODBC, os diré que la configuración es la misma para los equipos que se conectan desde dentro de la red que del equipo que estamos conectando desde Internet y lo único que cambia es dato del servidor que en un caso es PCSERVIDOR\SQLEXPRESS y en el otro es la IpExterna del servidor.

    Gracias de antemano por la ayuda que podáis prestarme.

    martes, 14 de agosto de 2012 10:42

Respuestas

  • Hola.

    Aunque es más que probable que sea algo más que esos 7200 los registros que se retornen para abrir el formulario, eso hecho ya da pistas de por dónde pueden ir los problemas. Debes limitar la información que se envía al cliente muchísimo más, muestra sólo lo que se solicite, y créeme, nadie lee más de 25 filas en un formulario, mandar más de 7000 es del todo innecesario.

    Para que tengas una consciencia más clara de qué se está ejecutando cada vez que abres la aplicación, deberías poner una traza de Profiler (un sniffer). Como usas una edición express, puedes emplear esta herramienta gratuita que hace algo similar:

    https://sites.google.com/site/sqlprofiler/

    Con esta herramienta podrás ver en realidad cuánta información se envía al cliente, cuánto tardan las sentencias, etc., lo que te permitirá afinar tu aplicación. Parece cuestión de ancho de banda, como dices, pero podrían ser otros factores adicionales, como instanciar la aplicación en sí (sin guardar relación con SQL Server).

    Si tienes dudas, nos dices.


    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.com
    Sígueme en twitter en http://twitter.com/qwalgrande

    • Propuesto como respuesta alfred_magno martes, 14 de agosto de 2012 16:07
    • Marcado como respuesta Eder Costa jueves, 16 de agosto de 2012 18:24
    martes, 14 de agosto de 2012 11:01
    Moderador

Todas las respuestas

  • Hola.

    Aunque es más que probable que sea algo más que esos 7200 los registros que se retornen para abrir el formulario, eso hecho ya da pistas de por dónde pueden ir los problemas. Debes limitar la información que se envía al cliente muchísimo más, muestra sólo lo que se solicite, y créeme, nadie lee más de 25 filas en un formulario, mandar más de 7000 es del todo innecesario.

    Para que tengas una consciencia más clara de qué se está ejecutando cada vez que abres la aplicación, deberías poner una traza de Profiler (un sniffer). Como usas una edición express, puedes emplear esta herramienta gratuita que hace algo similar:

    https://sites.google.com/site/sqlprofiler/

    Con esta herramienta podrás ver en realidad cuánta información se envía al cliente, cuánto tardan las sentencias, etc., lo que te permitirá afinar tu aplicación. Parece cuestión de ancho de banda, como dices, pero podrían ser otros factores adicionales, como instanciar la aplicación en sí (sin guardar relación con SQL Server).

    Si tienes dudas, nos dices.


    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.com
    Sígueme en twitter en http://twitter.com/qwalgrande

    • Propuesto como respuesta alfred_magno martes, 14 de agosto de 2012 16:07
    • Marcado como respuesta Eder Costa jueves, 16 de agosto de 2012 18:24
    martes, 14 de agosto de 2012 11:01
    Moderador
  • Ok, tomo nota, aunque soy consciente de lo que me dices y eso me obligaría a cambiar el funcionamiento de la base de datos y, ahora que la he transladado a SQL Server modificar algunas cosas para que se ejecuten desde el lado del server. Aún así me da vértigo solo de pensarlo, la base es monstruosa con infinidad de formularios.

    El jueves haré los test con el software que me recomiendas y ya cuento que resultados obtengo.

    Gracias por responder.

    martes, 14 de agosto de 2012 20:14
  • Lo mismo me sucede, aunque la conexion es local (LAN).  Front-End Access vs BackEnd Access funciona en velocidad normal/rapido, las sentencias dentro de  SQL Server funcionan igual o un poco mas rápido que en Access.  Pero, Front-End Access vs BackEnd SQL Server Express funciona terriblemente lento... que hicieron Uds que les funcionó?  En nuestro caso NO tenemos formularios que carguen miles de registros, y repito, es acceso LAN, pero de todos modos va demasiado lento, no se puede trabajar, es inviable

    Ayuda por favor

    Joseph

    proyectos@americancort.com

    viernes, 24 de octubre de 2014 16:03