aplicación cliente servidor?

[Giniromero]

Hola,


Estoy gestionando una aplicación delphi, con interbase 7.

Se tiene que gestionar en dos oficinas, que se comunican por una linea dedicada, a través de router y rdsi.

Mi problema es que cuando utilizan la aplicación en la oficina en la que se encuentra el servidor va todo bien, pero en la otra oficina, tardan algunas funciones como 6 veces más.

Tengo todo basado en consultas, no uso tablas enteras.
Utilizo TibDataset.


estamos pensando en comprar un servidor más potente, pues el que tenemos esta ya algo viejo, pero por ahora no parece que podamos aumentar el ancho de banda entre las oficinas, y no sé si un servidor más potente realmente ayudaría, pues creo que la aplicación no está montada en cliente servidor, y por tanto no es el propio servidor el que gestiona todas las funciones.



Alguna idea?

que haríais vosotros?
que cambiariais?
donde estoy metiendo la pata?


Muchas gracias por la ayuda y feliz año nuevo a todos

Vir

[__cadetill]

Hola Virginia

Personalmente creo que el cuello de botella lo tienes en las comunicaciones. No creo que cambiando el servidor consigas aligerar en exeso el tema de los retardos.

Actualmente y, por el precio que tiene, quizás una ADSL aunque sea de 256kb..... con eso seguro que sí aconseguiriais algo de mejora en el rendimiento (la RDSI no pasa de 64-128kb).

[Giniromero]

Hola,

Se que tienes razón, pero hemos estado valorando la posibilidad de ADSL, por que, efectivamente nuestro ancho de banda es sólo de 128kb, pero el problema de este sistema de comunicación es que, la red ATM, a fin de cuentas, es compartida, y por tanto, la velocidad depende de la cantidad de usuarios conectados a un tiempo, de modo que en algunos momentos, la velocidad puede verse reducida a la que tenemos ahora, por que el aforo en dicha red, esté en su "hora punta". Además de que va por el cable telefónico normal, (Analógico), y si en tu zona tienes "ruidos", por que sea muy antigua o tenga algún problema la linea, (lo cual es nuestro caso), no vas a tener nunca la velocidad que contrates. Esto no pasa con la RDSI o la fibra óptica. Pero, por ahora tengo que buscar soluciones para que la velocidad sea lo más óptima posible con lo que hay.


En cualquier caso, hay algo que no tengo muy claro, puede parecer un tema elemental, pero, ¿como hay que tener configurada la aplicación para que sea cliente servidor?, quiero decir, por lo que he leído, entiendo que este tipo de configuración hace que el trabajo lo gestione el servidor de la base de datos, no cada puesto, lo que mejora la integridad referencial respecto de la configuración de base de datos local con multiples usuarios, pero, ¿como hago para que así sea? quiero decir, que caracteristicas, de cara a la construcción del programa, hay que tener en cuenta? por que creo que es la que se ha usado para crear mi aplicación, pero, después de la documentación que he estado leyendo, no lo tengo tan claro.

Muchas gracias, de antemano, por la ayuda,

saludos,

Virginia

[__cadetill]

Bueno, en una app cliente/servidor, de lo que se trata es que el servidor sea el que más trabajo se lleve, es decir, veamos, hay que intentar acotar muy bien las consultas SQL, crear Procedimientos Almacenados, Triggers, definir bien los índices, una buena relación de integridad (cascada o delete según sea el caso),....., es decir, cosas que haga trabajar al servidor y que haga mínimo el tráfico por la red.

En definitiva, el cliente ha de ser un programa "tonto" (y nótese muy bien las comillas) que sólo le pide datos al motor de bases de datos (o bien procedimientos que hagan cálculos).

Por ejemplo, si tenemos un "mega listado" que ataca a 25mil tablas, es preferible montar un Procedimiento Almacenado que lo genere (y que rellene alguna tabla temporal por ejemplo) y, la aplicación cliente que sólo lea esa tabla temporal para luego volcarla en un QR o lo que sea.

Bueno, no se si me he explicado muy bien, es que el tema es bastante abstracto y no se como explicarlo :o :p

[kinobi]

Hola,

Giniromero comentó:
En cualquier caso, hay algo que no tengo muy claro, puede parecer un tema elemental, pero, ¿como hay que tener configurada la aplicación para que sea cliente servidor?, [...]

no es tanto una cuestión de configuración (que también) como de diseño. Un sistema (aplicación, entorno, arquitectura, ... al nivel que estamos hablando los términos son intercambiables) cliente/servidor se basa en la existencia de al menos tres entidades: un proceso servidor (o varios), un proceso cliente (o varios) y un mecanismo de comunicación entre los dos primeros. Un ejemplo típico es el sistema en el que dejamos mensajes en este foro: procesos servidores (al menos dos: un servidor http [web] y un servidor de base de datos [para almacenar los mensajes]), procesos clientes (nuestros navegadores) y un mecanismo de comunicaciones (la pila de protocolos tcp/ip sobre diferentes sistemas operativos y las líneas de comunicaciones).

En tu caso concreto: es evidente que una aplicación diseñada para trabajar en una red local (seguramente entre 10 y 100 Mbps, tal vez 1000 Mbps) no puede trabajar con la misma "agilidad" cuando los clientes están en puestos remotos comunicados con líneas que oscilan entre 32 Kbps y los 512 Kbps. Es cierto que ciertas técnologías permiten mayores velocidades (ADSL puede contratarse hasta con 2 Mbps, incluso hasta 8 Mbps; contratación de paquetes de varios canales RDSI; uso de líneas de gran ancho de banda, ...), pero a un coste elevado. La solución pasa por economizar en el recurso que supone el cuello de botella: el tráfico de datos. ¿Cómo hacerlo?:

Uso de terminales "tontos". Los procesos servidores y clientes se ejecutan en un sistema central y sus resultados (digamos "pantallazos") se envían a los puestos remotos (terminales "tontos") por la línea de comunicaciones. Muchas aplicaciones corporativas (bancos y similares) todavía lo utilizan.

Acumulando transacciones (entendido como operaciones, sean del tipo que sean) en los puestos remotos (allí donde se ejecuten las aplicaciones clientes) para enviar posteriormente al servidor(es).

El enfoque distribuido (en varias capas). La aplicación cliente(s) no se comunica directamente con el servidor, sino con un servidor(es) intermedio, cercano geográficamente al cliente y por tanto con un tiempo de respuesta menor.

Todo lo anterior es una descripción muy somera. Existen alternativas en forma de combinaciones de las anteriores.

Saludos.

[__cadetill]

Suerte que ha venido el amigo kinobi con una explicación algo más técnica que la mia :D (gracias :p)

[kinobi]

Hola Cadetill,

cadetill comentó:
Suerte que ha venido el amigo kinobi
No había visto tu respuesta. Coincidimos respondiendo a la vez :)

cadetill comentó:
con una explicación algo más técnica que la mia
Pues yo considero más técnica (o concreta) la tuya, y seguramente más en la línea de lo que pregunta Giniromero. La mía es una divagación quizá demasiado superficial.

Saludos.

[Giniromero]

Hola a los dos,

la verdad es que los dos me habeis sido de mucha ayuda, entiendo que de algún modo, efectivamente, mi aplicación es cliente servidor, tiene consultas SQL, usa disparadores, generadoradores, además de usar los IBX de delphi para su conexión con interbase, ... pero supongo que podría mejorarse utilizando, además, procedimientos en la propia base de datos.

El problema es que cuando he intentado crear alguna de estas, me ha dado porblemas, supongo que por que no sé muy bien como hacerlas, he podido suplirlas con código en la propia aplicación, y eso me ha hecho no tener que pegarme con ellas, por lo que esa parte casi no la conozco.

La documentación que tengo no me a sido de mucha ayuda tampoco.

Algún libro o artículo que me podais recomendar?

Muchas gracias, como siempre, por toda vuestra ayuda.

Virginia

[__cadetill]

Bueno, yo normalmente he tirado de los manuales de Interbase, en los que está bastante bien documentado (aunque en inglés) y luego de la información que dan con las nuevas versiones (trabajo con Firebird)

De los manuales de Interbase, si no los tienes ya, en la sección de Interbase del Club creo recordar que tienes los lincs

Valor y al toro que dicen ;)

[Delfino]

Creo q te puede interesar este articulo http://community.borland.com/article/0,1410,27653,00.html sobre como hacer las transacciones lo mas cortas posible para agilizar el trafico por la red, espero te sirva..

[guillotmarc]

Hola

En http://interbase.com.mx puedes encontrar algún artículo en castellano, como introducción a la utilización de procedimientos almacenados.

Aunque es bastante básico, y una vez superada esa introducción la mejor referencia es el propio manual de Interbase, como ha comentado Cadetill.

Saludos.

[Giniromero]

Hola a todos y muchas gracias,

Estoy echando un vistazo a lo que me habeis recomendado.

Muchas gracias a todos.

En cuanto a lo de que el manual de interbase está bastante bien documentado.... no lo dudo, pero, aunque sé inglés, me pierdo. Supongo que cuando aprenda bien la terminología y lo que implica cada cosa, me resultará más fácil seguir la documentación.

Un saludo a todos, y gracias de nuevo.

Virginia

Por cierto, ¡¡¡vaya cambio la página!!! :)

[ASAPLTDA]

He usado dos diferentes modelos y he tenido algunas mejoras de velocidad, y algunas dificultades
1. usar mis clientes remotos como terminales remotos de terminal server, los clientes han sido linux y windows , el servidor windows 2000 server
2. He usado en data modulo tablas en memoria para efectuar algunas validaciones del lado del cliente y son muy veloces excepto por dos puntos , la carga inicial y cuando las tablas han sido actualizadas en el servidor no se cual registro se modifico y recargo las talas de memoria nuevamente

3. Reducir al miimo la cantidad de datos transmitdos por la red
ejemplo si el archivo de clientes 10 campos y requiero 2 solamente efectuao la lectura de los 2 campos

Este es mi pequeno aporte

Carlos