| Ver tema anterior :: Ver tema siguiente |
| Autor |
Mensaje |
laremi400
Master
Registrado: 12 May 2004Mensajes: 179
|
 Publicado: Lun 30 Oct, 2006 10:48 am Asunto: Conectar sin ODBC |
 |
|
Hola!!
Tengo una aplicación cliente/servidor en la que el servidor está conectado mediante VPN, es decir, está en la misma red, pero en localizaciones distintas, de ahí la VPN.
Toda la aplicación se conecta mediante ODBC. En los lugares en donde la conexión es "directa" (en la misma localización que el servidor, conexión SIN VPN) la respuesta es inmediata.
Pero en los lugares donde la cenxión es mediante VPN la conexión es mucho más lenta. Lógico, claro, hay muchas cosas enmedio.
Hasta aquí ningún problema.
El caso es que intento optimizar mi aplicación y me encuentro con una cosa muy curiosa. La siguiente consulta:
| Código: |
Select Referencia,Sum(Palets) as TotalPalets,
Sum(Cantidad) as Total,Descripcion
from Ubicaciones
left join Referencias on UbiReferencia = Referencia
where RefCliCIF = 'XXX'
and UbiReferencia = 'XXX001122'
and RefDpto = 'Dep'
Group by Referencia,RefDescripcion
Order by Referencia
|
Esta consulta devuelve sólo 1 registro.
Si ejecuto esto desde la consola del analizador de consultas del SQL Enterprise Manager (SQL SERVER 2000) la consulta tarda 1 Segundo.
Si ejecuto la misma consulta desde mi aplicación tarda ¡16 segundos!!!!.
Si la consulta se complica con más campos, o más cálculos, en la consola aumenta mucho de tiempo pero la proporción de la diferencia entre consola y programa se dispara en progresión geométrica. No digamos si meto un UNION o un NOT IN, o las dos cosas en la misma consulta; la consulta en la consola llega hasta 3 minutazos y pico y mi programa se acaba bloqueando.
Esto me lleva a la conclusión de que la consola se conecta de otra manera distinta que la que se hace a través de ODBC.
¿Alguien sabe de que manera se hace esa conexión?
¿Esto es realmente así o es que hay algo más que no estoy teniendo en cuenta?.
Gracias mil. |
|
| Volver arriba |
|
 |
alfredo
Master
Registrado: 13 Oct 2003Mensajes: 246Ubicación: Valencia Venezuela
|
| Publicado: Mar 31 Oct, 2006 5:24 pm Asunto: |
|
|
No he trabajado con SQL Server pero supongo que habra algun modo de conectarse nativamente, es decir a traves del API de alguna libreria provista para la parte cliente, como por ej en Interbase es la Gds32.dll.
Mira si esto te sirve http://www.sqlapi.com/ |
|
| Volver arriba |
|
|
laremi400
Master
Registrado: 12 May 2004Mensajes: 179
|
| Publicado: Jue 02 Nov, 2006 11:29 am Asunto: |
|
|
OK. Mil gracias.
Algo asi es lo que quiero pero gratis, claro. O mejor haciendomelo yo. |
|
| Volver arriba |
|
|
Touchsoftwares
Master
Registrado: 16 Dic 2002Mensajes: 869Ubicación: MEXICO Playa del Carmen
|
| Publicado: Vie 03 Nov, 2006 6:57 am Asunto: |
|
|
No creo que sea problema de odbc.. ese tiempo de 16 segundos..me late a la configuracion de la consulta, esats haciendoel "->Prepare" antes del ->Open?
el cursor lo tienes del lado del servidor?
sobre todo por que es un registro el que devuelve y tarde un segnudo de manera local..calculando 3 segundo (muy lento) para qeu viaje por la red seria 4 seg.
La velocidad de bajada y/o subida del server es correcta?
ya probaste con otras consulta?
_________________
Ing. Gabriel Góngora Navarrete
TouchSoftwares Inc
http://www.touchsoftwares.com |
|
| Volver arriba |
|
|
laremi400
Master
Registrado: 12 May 2004Mensajes: 179
|
| Publicado: Vie 03 Nov, 2006 8:35 am Asunto: |
|
|
| Touchsoftwares escribió: | No creo que sea problema de odbc.. ese tiempo de 16 segundos..me late a la configuracion de la consulta, esats haciendoel "->Prepare" antes del ->Open?
el cursor lo tienes del lado del servidor?
sobre todo por que es un registro el que devuelve y tarde un segnudo de manera local..calculando 3 segundo (muy lento) para qeu viaje por la red seria 4 seg.
La velocidad de bajada y/o subida del server es correcta?
ya probaste con otras consulta? |
Gracias por tu respuesta.
No hago el prepare. Ahora mismo lo pruebo.
El cursor no sé ni donde se define. Voy a mirarlo.
¿Como calculas 3 seg.?
La velocidad de bajada/subida es la que hay, no creo que tenga muchas posibilidades de aumentarla, es una VPN conectada mediante un ADSL de ¿4 Mb?
Y sí he probado con otras consultas. Esta que puse es de ejemplo. en general las demás son lentas (yo supongo que por la VPN y por que hacen 17 cosas más a la vez en el ordenador) pero me permiten trabajar. En esta no había manera.
Gracias de nuevo. |
|
| Volver arriba |
|
|
laremi400
Master
Registrado: 12 May 2004Mensajes: 179
|
| Publicado: Vie 03 Nov, 2006 1:05 pm Asunto: |
|
|
Bien, ya he realizado las pruebas.
El ejemplo lo puse con 1 registro. El proceso real tarda 20 minutos y maneja 1119 registros. El programa hace cantidad de cosas (cálculos, presentación en pantalla) con cada registro.
Bueno pues he probado como decías y hay un par de cosas:
El Prepared: ni se ha notado. Hace lo mismo.
El Cursor: Los procesos se ralentizan muchisimo. Si se trabaja con el cursor en el lado del servidor, cada operacion que haces con los datos que devuelve la consulta la tienes que hacer desde el, servidor y entre éste y el ordenador en el que se trabaja tiene una VPN. Y esto hace que se ralentice mucho el trabajo. Supongo que la "conversación" con el servidor aumenta la carga de la red y esto es lo que ralentiza la tarea. Es decir, cada operación que haces con un registro tiene que viajar a través de la red. Si trabajas con el cursor en el lado cliente, los datos viajan por la red una sola vez, se alojan en la memoria de la máquina cliente y se procesan por ahí. El resultado es que frente a los 20 minutos que tarda el proceso ahora, con el cursor al lado servidor, el proceso tarda 41 minutos. Los tiempos están redondeados a la baja.
Así que seguiré investigando. Gracias por tu respuesta de todas formas. |
|
| Volver arriba |
|
|
juanma
Cmdr
Registrado: 17 Nov 2005Mensajes: 127Ubicación: Almeria - España
|
| Publicado: Vie 03 Nov, 2006 3:21 pm Asunto: |
|
|
Solo comentarte q mi experiencia con manejo de datos a traves de una VPN es lento... piensa en el cuello de botella q supone la salida por internet compartida para todos los de la red local (y si alguno esta descargando algun programa, el ancho que quedaria para lo demas...).
Creo que touchsoftware te ha dado un poco la clave: el cursor en el lado servidor de forma q tu envias la consulta y te llegan solo los datos necesarios, de otra forma la cantidad de datos q se mueven serían enormes en proporción a los q se necesitan. A veces en una base de datos nueva se lleba uno a engaños porque hay muy pocos datos y aparentemente todo va rápido.
Yo no he encontrado grandes diferencias entre enlazar los datos de forma nativa o con ODBC en una VPN, solo podras conseguir mejores resultados a traves del diseño da la base de datos (y sobre todo los campos de los where que esten en indices...) |
|
| Volver arriba |
|
|
Touchsoftwares
Master
Registrado: 16 Dic 2002Mensajes: 869Ubicación: MEXICO Playa del Carmen
|
| Publicado: Lun 06 Nov, 2006 6:09 am Asunto: |
|
|
| Cita: |
El ejemplo lo puse con 1 registro. El proceso real tarda 20 minutos y maneja 1119 registros. El programa hace cantidad de cosas (cálculos, presentación en pantalla) con cada registro. |
Por lo que entiendo tienes varias consultas en un ciclo for?, es asi?
si es afirmativo, la consulta no es la lenta, si no el proceso en el ciclo, veoque son 1119 registros, son pocos para una consulta, pero MUCHOS para hace 1119 consultas, me explico?
Ataca el problema de otra manera.. por ejemplo, lee los registros en memoria y/o has UNA sola consulta donde esten todos los resultados y las separas ya en un ciclo form pero en memoria, no se si me explico...
_________________
Ing. Gabriel Góngora Navarrete
TouchSoftwares Inc
http://www.touchsoftwares.com |
|
| Volver arriba |
|
|
laremi400
Master
Registrado: 12 May 2004Mensajes: 179
|
| Publicado: Lun 06 Nov, 2006 9:44 am Asunto: |
|
|
| Touchsoftwares escribió: | | Por lo que entiendo tienes varias consultas en un ciclo for?, es asi? |
No. Tengo una consulta, que devuelve esos 1119 regs.
| Touchsoftwares escribió: | | Ataca el problema de otra manera.. por ejemplo, lee los registros en memoria y/o has UNA sola consulta donde esten todos los resultados y las separas ya en un ciclo form pero en memoria, no se si me explico... |
Perfectamente, pero eso es lo que hago ahora. Por lo menos eso creo. Si haces una consulta, te devuelve un dataset, que se almacena en la memoria de la máquina, (cursor en el lado cliente y tal). Una vez que ya lo he traído desde el servidor, hago cosas con él.
Pero aún y todo, va más lento que hacerlo desde el administrador de SQL SERVER. |
|
| Volver arriba |
|
|
Touchsoftwares
Master
Registrado: 16 Dic 2002Mensajes: 869Ubicación: MEXICO Playa del Carmen
|
| Publicado: Vie 10 Nov, 2006 4:27 am Asunto: |
|
|
Que longitud (bytes) tiene cada registro? , no tiene campos blob o algo similar?
Estas seleccionando solo los campos que necesitas?
La verdad se me hace muy lento 20 minutos por 1100 registros ,pensando que son integer, float y alguno que otro varchar
_________________
Ing. Gabriel Góngora Navarrete
TouchSoftwares Inc
http://www.touchsoftwares.com |
|
| Volver arriba |
|
|
laremi400
Master
Registrado: 12 May 2004Mensajes: 179
|
| Publicado: Vie 10 Nov, 2006 8:54 am Asunto: |
|
|
| Touchsoftwares escribió: | Que longitud (bytes) tiene cada registro? , no tiene campos blob o algo similar?
Estas seleccionando solo los campos que necesitas?
|
Unos 30, hablo de memoria, pero si miras la consulta del primer post, es un varchar, y dos numeric (serán long supongo).
| Touchsoftwares escribió: | | La verdad se me hace muy lento 20 minutos por 1100 registros ,pensando que son integer, float y alguno que otro varchar |
A mí también, de ahí venía el post. Pero no lo he conseguido solucionar. Buscaré librerías y cambiaré de componentes hasta que consiga mejorar el rendimiento, pero no tengo esperanzas de que mejora tal y como lo hago ahora. |
|
| Volver arriba |
|
|
laremi400
Master
Registrado: 12 May 2004Mensajes: 179
|
| Publicado: Lun 13 Nov, 2006 5:11 pm Asunto: |
|
|
Bueno, encontré una solución. Incluso con más registros, el tiempo que tarda ahora en devolverlo en mínimo. dos o tres segundos.
Lo que he hecho es conectar las query directamente a ODBC
Hasta ahora usaba un componente TADOConnection. en este componente definía la cadena de conexión especificando los controladores OBDC para SQL SERVER y luego a cada TADOQuery le decía que usase esa conexión.
Ahora denfino la cedna de conexión en cada TADOQuery.
Con eso han desaparecido los problemas de velocidad. |
|
| Volver arriba |
|
|
|
FAQ
Buscar
Miembros
Grupos de Usuarios
Registrarse
Perfil
Entra para ver tus mensajes privados
Entrar
