Ayuda con Firebird + Internet

[joselgz]

Lamento decirles que ninguna persona que dio su opinion y las que respeto fue exacta, despues de todo este tiempo de investigacion di con la solucion para el problemita de internet y firebird todo esta resumido en que "firebird no tiene soporte para la compresion de paquetes ip", cosa que mysql si posee, no quiero decir con esto que mysql sea mejor. La solucion del asunto fue la instalacion de ZeBeDee que es un software que permite realizar una conexion encriptada, y comprime los datos tcp/ip o udp. Esa fue la verdadera solucion. Señores yo lo probe y doy fe que es la solucion, ninguno de las personas que dieron su opinion y la cual respeto estaba claro en lo que decia. Mis disculpas si ofendi a alguien, cualquiera pregunta tecnica con respecto a esto lo puede hacer a mi correo joselgz@hotmail.com

[xander]

Todo mundo aqui te ha compartido de su experiencia, los consejos de Casimiro, Emilio y demás colegas tal vez no te sean de utilidad a ti, pero para alguien mas serán el primer punto a revisar en sus aplicaciones.

Creo que deberías de compartir la solución que funcionó para ti, el tipo de aplicación que hiciste, cuantas solicitudes haces a la base de datos y de cuantos registros, y cuanta mejora en tiempos y trafico obtuviste con la solución que encontraste. Yo te puedo hablar con conocimiento de causa que el Zebedee no me ofreció un beneficio tangible porque mis demoras generalmente son sobre la preparación de las consultas como lo habia externado en otro hilo, ahi Zebedee no me puede ayudar en acelerar la preparación de las consultas en los clientes, siempre voy a tener una demora de por lo menos 3 segundos en preparar la consulta ya sea con o sin zebedee.

Por eso te digo que si compartes la configuración que para ti dio resultado tal vez le ayudes a alguien mas que en el futuro tenga una aplicación como la tuya.

[jachguate]

Amigos, lamento llegar tan tarde a este hilo, pero con algun tiempo de inactividad me lo perdí en vivo.

Comparto mi experiencia:

Sobre enlaces tan reducidos como 512 kbps, la aplicación debe pensarse desde el inicio para la transmisión del mínimo de información entre el servidor de base de datos y el cliente, de manera que pueda sacarse un rendimiento decente. Esto significa no abrir tablas de mas, nunca traer mas registros de los necesarios, y -siempre que sea posible- hacer un cache del lado del cliente con la información que cambia con poca frecuencia, estableciendo una buena política de actualización de dicha información.

Para lograr un arranque lento de la aplicación, puede lanzarse las consultas de la información requerida para iniciar en segundo plano, mientras que la aplicación muestra cuanto antes menus y otros elementos de la interfaz de usuario. Si el usuario quiere realizar una operación para la que aún falta bajar algún dato, se le puede hacer esperar un momento, pero si se ha cumplido lo que he dicho primero, en el tiempo que este tarda en tomar el mouse, entrar a un formulario e intentar hacer algo, seguro que ya todo está en su sitio.

Estoy con Xander: un compresor de paquetes ayudará solamente si la información que viaja es mucha y en trozos grandes. Para algunas operaciones, no representa beneficio alguno.

No logro imaginar una consulta que tarde 3 segundos en prepararse en un servidor firebird, a menos que el servidor esté muy ocupado con otras cosas. Aún en este caso, una buena solución es mandar a preparar la consulta y mantenerla preparada, de manera que si se ejecuta 10 veces, los 3 segundos ya mencionados solamente se "invirtieron" una vez. Dicha preparación, incluso, puede hacerse antes que el usuario llegue a necesitar de la consulta.

Finalmente, decir que no cualquier aplicación puede correr sobre seguro en tales condiciones. Para las que no, hay otras alternativas, como citrix, que estamos usando en la empresa actualmente con un buen grado de éxito. Las aplicaciones están contiguas al servidor, en una red de 1 Gbps, por lo que son muy rápidas, y citrix consume solamente unos 24Kbps por usuario conectado, con lo que en un enlace de 512 caben unos cuantos...

Hasta luego.

[joselgz]

Basicamente la aplicacion maneja los informes patologicos de un laboratorio de diagnostico anatomopatologico, maneja 32 tablas, unas cuantas vistas, unos cuantos procedimientos y algunos disparadores. Las tablas maestras manejan entre 20 y 100 registros, y otras mas de 30.000 hasta los momentos. Algunas de estas tablas manejan campos memo y binarios (ambos inclusive) para fotos. Esta aplicacion se ha estado desarrollando en el transcurso de 3 años. La aplicacion ha sido objeto de multiple revisiones con lo cual a alcanzado un nivel muy bueno aunque se podria decir que excelente segun comentarios de otros colegas del doctor al cual le desarrolle la aplicacion. El problema se presenta cuando se quiere dar el paso para que la aplicacion sea accesada desde otro punto que no sea el sitio de trabajo. Se contrato el servicio de banda ancha a 720 kbps mas el ip estatico, al realizar las pruebas se observa que aunque la conexion es perfecta ni siquiera la aplicacion de administracion de firebird logra acceder de manera rapida las tablas ni consultas, al probar con la aplicacion sucede lo mismo, estamos hablando de tiempos hasta de 30 - 45 segundos para desplegar la data de una tabla. Lo demas se resume en lo que esta en el foro. En venezuela hay una aplicacion administrativa muy popular y muy buena denominada Valery y observe que muchas personas tenian el mismo problema, vi en el foro de ellos alguien que utilizo el tunnel, hice la investigacion y realize las conexiones, para mi sorpresa los tiempos bajaron drasticamente hasta en 3 segundos, que en comparacion 3 segundos a mi parecer son tiempos aceptables. La configuracion utilizada fue la normal que aparece en la pagina del Zebedee. Si hay alguna otra pregunta hacermela llegar directamente a joselgz@hotmail.com

[xander]

asi es... 3 segundos es lo mas o menos el tiempo que se tarda el firebird en preparar una consulta remotamente (me refiero a via internet), claro que una vez preparada el tiempo es infimo con pocos datos (de unos cuantos milisegundos)... ahi es donde decia yo que IBObjects o alguna suite que maneje sesiones persistentes en el servidor es muy util pues va trayendo los registros sobre demanda, yo puedo asegurar que me tarda el mismo tiempo en abrir por internet una consulta de 10,000 registros que una de solo 10, ojo, no me refiero a reportear los 10,000 registros sino a abrir una consulta que los involucre.

claro que localmente dificilmente encontraras una consulta que se tarde 3 segundos en prepararse, pero via internet es lo menos que se tarda.

[jachguate]

Empezado por joselgz

Algunas de estas tablas manejan campos memo y binarios (ambos inclusive) para fotos.

Acá si que puede tener incidencia un compresor de paquetes, pero la misma (o mejor) incidencia tendría comprimir/descomprimir vos las imágenes al vuelo desde dentro del programa.

Empezado por joselgz

al realizar las pruebas se observa que aunque la conexion es perfecta ni siquiera la aplicacion de administracion de firebird logra acceder de manera rapida las tablas ni consultas

Firebird no tiene ninguna herramienta de administración integrada al proyecto. Supongo que usas algo como IBManager o IBAdmin. Lamentablemente estas herramientas (hechas con delphi) tampoco están pensadas ni optimizadas para trabajar sobre conexiones lentas... ¡Hacen tantas consultas al diccionario de datos y prácticamente suben a memoria todo el metadata de la base con solo intentar conectarse!

Si queres probar si la conexión a firebird por si sola es mas o es menos lenta, entrá desde isql:

SQL>connect miservidor.com:/home/jachguate/db/laboratorio.fdb user sysdba password masterkey;
SQL>select rdb$relation_name from rdb$relations;

Empezado por joselgz

al probar con la aplicacion sucede lo mismo, estamos hablando de tiempos hasta de 30 - 45 segundos para desplegar la data de una tabla.

¿Que resultados te arroja un análisis mas detallado de la operación "desplegar datos de una tabla"?

¿Tiempo para preparar la consulta?
¿tiempo para abrir la consulta?
¿tiempo para hacer fetch de los primeros 10 o 20 registros?
¿tiempo para hacer fetch de todos los registros?
¿cuantos registros son?
¿tienen campos blob?
¿haces fetch de los blobs junto con los datos de los otros campos?

Empezado por joselgz

Si hay alguna otra pregunta hacermela llegar directamente a xxx@hotmail.com

Por favor, ¡respetá la guia de estilo!, si no lo haces me veré obligado a cerrar este hilo.

[jachguate]

Empezado por xander

asi es... 3 segundos es lo mas o menos el tiempo que se tarda el firebird en preparar una consulta remotamente (me refiero a via internet),

¡No lo creo!

3 segundos se tarda tu aplicación en prepararla, pero es probable que tu capa de acceso a datos haga consultas al diccionario u otra información de la que precise para abrir la consulta, y eso ya es harina de otro costal, puesto que es algo sobre lo que firebird como motor no tiene control alguno.

Nuevamente, con isql recién hice una prueba sobre una conexión bastante lenta (donde el connect ha llevado aproximadamente 6-8 segundos), y la preparación de una consulta mas o menos complicada ha sido prácticamente instantánea.

Hasta luego.