Foros Club Delphi

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)
-   Firebird e Interbase (https://www.clubdelphi.com/foros/forumdisplay.php?f=19)
-   -   Eficientar Interbase para internet (https://www.clubdelphi.com/foros/showthread.php?t=81140)

Diego827 15-10-2012 07:59:42

Eficientar Interbase para internet
 
Hola Maestros del Club!

Desearia saber si alguien de ustedes a logrado "eficientar" la base de datos Interbase para ser usada a travez de internet como sistema cliente-servidor.

Les comento: tengo una base de datos Interbase SMP 2009 en un servidor con conexion a internet. Sin embargo, mi conexion de subida es pobre, 512 kbps. Los programas clientes están conectados por medio de componentes Interbase (a veces denominados IBX).

La configuración actual de la base de datos es la default. Es decir, instalé, cree la base y punto.

Otro dato es que los clientes mantienen la sesion en la Base de datos hasta que cierran el programa cliente desarrollado en C++ Builder (hermanito menor de Delphi XD). Sin embargo: como pueden saberlo muy bien, funciona lento.

Mi pregunta es: como configurar Interbase para que funcione de la mejor forma posible. No se si esto es posible.

Siempre he recibido buenos consejos de ustedes. Espero sus comentarios. No importa si son para regañarme :D digamos que soy novato empedernido.

En resumen: ¿Cómo volver eficiente la conexión de un cliente a un servidor en Internet con Interbase?

(por cierto, se que no es eficiente lo que hice pero no se nada de html y mucho menos php; por ello hice la aplicacion de esta forma).

Saludos desde América Central!!!

Casimiro Notevi 15-10-2012 10:11:41

Trabajar por internet como si fuese una red local es lento, ¿el motivo?, pues que internet es más lento que una red local.
Una red local "normal" va a 100 o 1000 Mbits, pongamos el caso de 100 que es lo habitual: 100 Mbits = escasamente 10 Mbytes.
Ahora calculemos una conexión de internet, lo "normal" por aquí es 1 Mbit de subida y 20 Mbits de bajada (teóricamente, ya que la práctica es la mitad), bien, eso nos deja en: 1 Mbit= 10 Kbytes "redondeando" y de bajada tenemos 20 Mbits= 2 Mbytes.
Resumiendo:
Cita:

--------Red local------Internet---
Subida-----10 MB----------10 KB
Bajada-----10 MB-----------2 MB
----------------------------------

Por lo tanto para hacer un programa que esté conectado a un servidor por internet necesitas afinarlo muchísimo, muchísimo, muchísimo... básicamente sería trabajar como un cajero automático de los bancos, los datos mínimos imprescindibles y nada más.
Si quieres trabajar por internet entonces debes hacerlo como los programas webs "normales", que se ejecutan en el servidor y el cliente sólo es un terminal, por lo que lo único que "viaja" por la red son los cambios de pantalla, lo que se presenta.

Casimiro Notevi 15-10-2012 10:16:00

Sin embargo, interbase y firebird sí que son muy válidos para trabajar de servidores en internet.
Lo que "falla" es que un programa windows de la forma en que se hace para una gestión normal, para red local, no es eficiente por internet, independientemente de que sea interbase, firebird, mysql, postgresql, ms sql, oracle, etc. No es culpa de la base de datos, ni de delphi, por supuesto, sino que no es la forma adecuada.

Diego827 15-10-2012 21:03:53

Nada que revatir
 
Hola estimado Casimiro:

Ya extrañaba tus jalones de oreja. Tienes toda la razón.

Se que en una red local que utilice los estándares:
Ethernet las velocidades son 1mbps a 10 mbps
Fast-ethernet: 1-10-100 mbps
Gigabit Ethernet (o GEthernet): 1-10-100-1000 mbps (observese la "b" en minuscula, "b"its).

Y tal como lo mencioné anteriormente sé que no es la forma y que trabajará todo lento por no ser una LAN sino en todo caso una Internetwork. Pero, mi pregunta iba mas hacia lo que tu mencionaste en algún lugar: "los datos mínimos imprescindibles y nada más"; es eso exactamente lo que desearía saber; si existe alguna configuración para que los datos de "control" entre el cliente y el servidor sean mínimos.

En una red de área local (LAN) se intercambian demasiados datos de control y desearia saber si existe al menos un método de compresión (¿como en Oracle? creo que estoy hablando pavadas) o que se yo (más inexperto imposible :() para la reducción de éstos datos.

Muchas gracias por su tiempo amigos.

Casimiro Notevi 15-10-2012 21:14:37

Sí, puedes comprimir los datos, pero eso no soluciona el problema.
Repito lo del ejemplo: un cajero automático de banco. ¿Qué pide?, password (pin).
Elija opción: sacar dinero
Escriba cantidad: 20

¿Quiere hacer otra transacción?: si
Se desconecta, vuelve a conectar y pedir la clave (pin)
Elija opción: ver saldo
Tiene usted: 100

¿Quiere hacer otra transacción?: no
Recoja su tarjeta y que tenga un buen día.

Diego827 15-10-2012 21:26:48

Gracias!!!
 
Ahora te entiendo. Tienes toda la razón!

Tengo un amigo que trabaja reparando ATMs y el me comenta que estos trabajan en una VPN+, la misma es en sí lenta pero se conectan solamente cuando requieren datos.

Muchas gracias Casimiro, tal vez no es la solución absoluta, pero si una buena opción.

Te agradezco mucho ;)

PD: creo que se llaman: conexiones orientadas a la conexión y las otras orientadas a la desconexión; las orientadas a la conexión consumen mucho más (obvio) que las no orientadas.

Casimiro Notevi 15-10-2012 22:24:37

Otra cosa que puedes hacer es ejecutar el programa en el servidor, donde está firebird, y que los terminales ejecuten un programita del tipo terminal server, esa opción funciona bien.
La otra opción es hacer un programa web.

De todas formas, en el modo tradicional (hacer tu programa delphi y ejecutarlo en cada cliente) si tienes cuidado puede ir aceptablemente bien, lo que tienes que hacer es no traerte tablas completas, los datasets únicamente los datos mínimos imprescindibles, nada de "select * from loquesea", eliminar esas opciones de ir tecleando mientras van apareciendo los registros según se pulsan las teclas, etc. etc. etc.
Ya digo, yo tengo hecho algunas cositas que funcionan por internet y va rápido, tan rápido como puede ir en red local, pero teniendo mucho, mucho, mucho, mucho cuidado en lo que se hace, depurando cada opción que sea lenta hasta dejarla ágil, eliminando funcionalidades que enlentecen, etc.
Por ejemplo, siempre hay pequeñas tablas que se usan en todas partes, en una gestión pueden ser las tablas de IVA, la de datos generales, etc. pues esas tablas leerlas una vez y mantenerlas en memoria en un tabla en memoria, ya que son escasos 3 registros.
Con pequeños truquitos de ese tipo se consigue ganar mucho en rendimiento.

cointec 16-10-2012 00:33:39

Hola, no se qué tal funcionará ya que no lo he probado, pero podrías intentar utilizar zebedee. Puedes realizar un túnel y la información puede viajar encriptada y comprimida. Se gana en velocidad al tener que transferir menos datos, ya que es el cuello de botella que tienes. No se qué ganarás con ello, pero lo puedes probar sin necesidad de cambiar nada en tu aplicación.

Otra opción es convertir la aplicación en tres capas y utilizar una librería como dataabstract o datasnap.

Por último, comentarte que se está trabajando en optimizar el protocolo de red de firebird para optimizar lo en conexiones lentas, como este caso. No se lo que se ganará y si tu aplicación funcionará fluidamente con el, pero esta opción tardara un tiempo en salir.

ASAPLTDA 01-11-2012 22:45:12

Data Abstract Remobjects
 
Cita:

Empezado por cointec (Mensaje 447185)

Otra opción es convertir la aplicación en tres capas y utilizar una librería como dataabstract o datasnap.

Hola seria posible que nos contaras tu experiencia con Data Abstract

cointec 02-11-2012 15:42:39

Hola, realmente no te puedo ser de mucha ayuda. A principios de año adquirimos los componentes con la intención de poder migrar nuestra aplicación de dos a tres capas, pero por diversas razones, aún no hemos podido empezar con ello.

mamcx 02-11-2012 17:50:23

He actualizado una presentacion sobre remobjects:

http://blog.elmalabarista.com/post/1...ion-remobjects


La franja horaria es GMT +2. Ahora son las 12:12:22.

Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi