Problemas de performance C/S en entornos distribuidos
 

Estimados:
Tenemos una aplicación C/S que corre razonablemente en un entorno de red local. Utilizamos Delphi 6, Firebird 2.1 con Midas y el driver dbexpida. El problema surge en un cliente que tiene servidores virtuales en USA con el motor de base de datos remoto y la aplicación corriendo localmente. La aplicación tarda mucho en abrir todas las tablas lookup y despues tirar un query sobre un registro particular. Es mucho más rápido hacer los lookups en el mismo query aunque el volumen de datos sea mucho mayor y repetitivo. Es como que existe un penalty alto por transacción con la base de datos. Ni que hablar cuando el query usa lookups y nested datasets. Ahí nos quedamos a vivir adelante de la pantalla. Poniendolo en criollo es como que la base de datos nos "pide" que preguntemos todo de una, nos arma el paqueton y lo manda (y no jodamos más) y no que armemos los datos localmente pidiendole cada tablita por separado aunque el volumen de datos sea menor.
Alguna sugerencia para cambiar o mejorar esta cuestión?
Saludos, MC.

Estas pasando de tener una conexión local de minimo 100 MB a una de menos de 1/4 MB y eso optimista.

Aunque todo motor SQL puede accederse remotamente, la verdad es que estan optimizados para acceso en una red local o mejor, directamente.

Lo que puedes hacer:

1- Disminuye la cantidad de registros/datos en cada transaccion. Evita los SELECT * FROM Tabla por SELECT Campo1,CampoN... FROM Tabla WHERE Exactamente lo que quieres. Tambien el uso de procedimientos almacenados, donde mucho del procesamiento se hace en la BD y solo pasas y recibes datos puede ayudar.

2- Usa caches.

Por lo general todo sistema tiene mas tablas de "lookup" que son masomenos estaticas y una pocas transaccionales, que se mueve mucho.

Asi que puedes descargar las tablas mas estaticas y solo tener una conexion "viva" a las transaccionales. Las tablas pueden estar en un servidor firebird embeido local. Asi, tienes 2 conexiones de BD: La Bd de cache local y la de internet. Tambien puede servir el cache en memoria (aun mas rapido, pero los datos deben caber).

Basicamente, una mezcla de lo anterior, es lo maximo que se puede hacer

2a- Por ultimo, contratar un ancho de banda mas alto. Algunas empresas pagan por canales dedicados o planes de internet mas elevados para compensar por los sistemas C/S que no estan optimizados a internet.

3- Migrar a un framework N-Tier.

Si el proyecto lo amerita, migrarse a DataSnap (Tienes que usar Delphi XE2), RemObjects o similar es lo mas ideal.

En el caso de RemObjects, hay una opcion buena y gratuita:

http://www.remobjects.com/da/relativity.aspx

Ese es un servidor N-Tier que te da conectividad remota a cualquier motor de BD, firebird incluido. Utiliza un sistema que es MUY eficiente en sus comunicaciones, y te permite tirar SQL tal como lo conoces.

La parte mas dificil la consigues "gratis". La parte complicada es que debes crear una libreria de acceso usando REST o oDATA. Bueno, es ligeramente dificil.

Hola mamcx!

Gracias por tu pronta respuesta.
Te cuento lo que creo que es mi sospecha sobre este tema y vos me dirás si opinás que puede ser plausible o no.

Lo plantearía así:

"El problema de performance en una red distribuida no es la cantidad de datos que se transfiere, sino la cantidad de transacciones necesarias para obtener estos datos"

El problema me parece que tiene que ver con el tiempo de latencia de cada transacción.

Idea loca:
Si pudieramos levantar todas las lookup en un solo query sería mucho más rápido que levantarlas una por una, aunque el volumen de datos sea prácticamente el mismo. Por supuesto después habría que acomodar toda esa data mezclada en cada una de las lookups... Necesitaríamos un "broker intermedio que hiciera esta tarea.

Una solución es si n-tier, pero ahí entrás en cuestiones de políticas corporativas de si te dejan instalar un aplicativo de origen "dudoso" en un server de la compañia (con los motores de BD no tienen en general problema)

En fin, sigamos discutiendo este problema. porque la verdad es que con 1/4 de Mb/s se hacían maravillas hace unos años y ahora si no es con Gb. parace que nada andara... jeje siempre te tienen que vender más potencia.

MC.

usar Terminal server. Nosotros en nuestra empresa los usuarios de otras plantas se conectan a la aplicación por esta vía. Otra alternativa es x2client como acceso remoto. Nuestro sistema da servicio a 60 usuarios concurrentes.

En definitiva concuerdo con PepeLolo.

Yo también soy bastante partidario de usar terminal server para estas situaciones.

Saludos