FoxPro/Visual FoxPro - Sugerencias: Consulta por velocidad en la Red

Hola a todos!!

Necesitaría que me orientaran para mejorar la performance de un programa ya armado.

Estuve leyendo varios post, donde es-binario sugiere que lo mejor es trabajar con un esquema cliente-servidor en MySQL, por ejemplo, pero ahora el problema está y necesitaría solucionarlo así, mientras voy desarrollando la aplicación en paralelo con una base de datos externa.

Les comento el problema:
El programa (exe) está guardado en un servidor dedicado, donde, obviamente, el programa vuela. Los datos están almacenados en el mismo servidor, en una carpeta DATA
Como la aplicación comenzó siendo mono-usuaria, nunca había tenido problemas.

La empresa creció y empezaron a conectar terminales a la red. Siempre con el mismo esquema: mapear unidades de red al servidor y ejecutar la aplicación desde la unidad de red mapeada.

Ahora me encuentro que el programa funciona bien si los usuarios NO hacen un proceso simultáneo sobre la misma tabla o tablas.
Es decir, si uno hace una búsqueda de artículos mientras otro usuario está listando las existencia de artículos, la velocidad BAJA MUCHO y la red se pone re-lenta, pero para todos los usuarios.

Insisto: sé que la manera no es la óptima de programas, pero el problema ya está y me gustaría, al menos, mejorar lo que está hecho para buscar de mejorar la velocidad, ya que es un programa "viejo".
El tema es que antes la empresa usaba la misma red con un programa en Clipper y todo funcionaba bien.
Algunos datos de la red : Servidor: Core 2 Duo, 4 Gb de RAM, Windows 7, 8 terminales,

Datos del programa: VFP9, programado con las tablas en entorno de datos, en modo buffering para el trabajo en red

¿Tienen alguna sugerencia???

Muchas gracias

Bueno para mi el error esta en como lo haces

Digamos que con foxpro no se pudieran crear Aplicaciones cliente servidor ("no es cierto, pero supongamos"), supniendo lo anterior nuestra alternativa seria un tanto ingeniosa que eficiente, pero la hay y para mi eses es tu principal problema

Primer en el servidor debe estar unicamente en una carpeta compartida la base de datos y las tablas algo asi, es decir unicamente los datos y nuestra rupa para acceder a ellos seria algo asi:

\\Servidor\Datos_Empresa\Mi_base_de_datos\

Esa seria mi ruta, y cual es el unico cambio que tengo que hacerle a mi aplicacion, pues en el programa principal tenemos el OPEN DATABASE y deberia ser asi.

OPEN DATABASE \\Servidor\Datos_Empresa\Mi_base_de_datos\Datos.dbc

En teoria, pero como no fue pensada tu aplicacion para multiusuarios no tiene el lock sebre los registros cuando alguien quiera registrar algo, y es aqui donde se complica la opcion que me queda a mi parecer es ponerle un try catch antes de hacer una llamada a cualquier vista, por que para evitar problemas tendria que usar vistas y lo mismo a la hora de hacer un registro por lo tanto debo trabajar de todos modos en todos mis forms que tengan acceso a los datos.

Bueno otra opcion seria que el programa creara replicas de la base de datos, por ejemplo una replica por terminal y hay 2 formas una seria que hicieras otro program digamos en foxpro que creara la replica y asi la mantedria actualizada, la replica podria ser local si los datos son menores a <= 20Mb, de lo contrario tendrian que hacerse en el mismo servidor \\Servidor\Datos_Empresa\Mi_base_de_datos_Estacion1\Datos.dbc

Asi evitaria los conflictos correspondientes lo mejor es agarrar al todo por los cuernos y decirle a nuestro cliente que lamentablemente la aplicacion no fue dise;ada para tal tarea y que debe rehacerse bien, claro con su respectivo costo en el desarrollo, y me refiero al costo de tiempo y al costo del trabajo del desarrollador.

Yo tengo una Base de datos en Mysq en un ferreteria, bueno los forms tienen la conexion y cada estacion tiene una tabla usario y contrase;a en una dbf local que es con la que logea con mysql y nada mas no tengo nada mas, es decir es tan facil como eso, la base de datos esta toda en mysql y en mysql hay un usuario creado para cada estacion en este caso son 4 puntos de venta 1 caja para cobrar y 1 contable (el que da de alta los ingresos las facturas compras resumentes etc)

y no le tengo que decir, aver fijate si no la estan usando no se como lo hace la verdad pero mysql administra automaticamente el acceso a la base de datos segun los permisos de cada usuario es una unica aplicacion no son 2 ni tres es una solo, que solo tiene en el init su nombre de usuario con el que hace loggin en mysql.

y esto no se aprende de la nada hay libros documentos para hacerlo lamentablemente en ingles, pero ahora con el google traductor ya no hay tanto problema, yo me manejo asi, un formulario por dia y asi cotizo mis aplicaciones en tiempo - dinero, claro que muchas veces se puede desarrollar mas de un formulario por dia, pero minimo uno diario si se puede, y asi cotizo.

Saludos.

Yo te recomendaria que primero investigues si el problema es el servidor
o la aplicacion.

Te cuento tengo una aplicacion POS (venta) y la tengo
en la misma empresa pero en diferentes rubros y la tengo funcionando desde
monousuario hasta en 8 terminales, lo instalo sobre fedora6,8,10 u 11(linux)
el mejor servidor que tengo instalado es un celeron 2.00GHZ con 1GB ram y
160GB HD (ni siquiera es core duo!) y lo tengo del mismo modo que tu es decir
el exe y las DBF´s/CDX´s sobre el servidor, mi cableado de red funciona en
100mbps, la carpeta la mapeo a una unidad como Z:\ y funciona nadie se queja
al momento de cargar la aplicacion en ocaciones demora entre 3 y 5 segundos
pero luego no se palpa ninguna demora, yo diseñe mi sistema en VFP6.0 y vengo
desde clipper5.2.

Curiosamente en estos dias estuve comenzando a leer un libro PDF se llama la
cara oculta de C++ en donde el autor elogia a los programadores de clipper por
hacer funcionar sus sistemas en un compilador tan malo como el clipper hasta me
causo gracia!!! - tambien le pega duro al Xbase o sea a la estructura de las
tablas DBF´s, pero tiene razon en el clipper todo lo haces a mano y debes
ser super cuidadoso!!, porque te digo todo esto?, pues si tu no te tomas el
tiempo de diseñar bien las tablas cuando tenga cierta cantidad de registros
se tomara su tiempo en los accesos, por ejemplo por decirte las tablas
maestras como listado de productos debes poner simplemente los campos
imprecindibles para cualquier parte del sistema y todos los campos que no
necesites con urgencia sacalos en otra tabla, los indices hazlo lo mas
compacto posible (segun mi humilde experiencia son necesarias dos claves
codigo del producto y el nombre para busquedas) no solo porque en algun
reporte te conviene tener un cierto orden debes crear un indice compuesto
en dicha tabla, todos tus auxiliares debes enviarlos al disco local y no
usar el servidor para estos.

Si tienes una tabla con mucha cantidad de campos de numero o fecha grabalos
como cadenas estos son mas rapidamente accedidos puesto que no requieren
conversion al momento de leerlas ya sea por consultas o por recorrer la tabla,
solo debes convertirlos de vuelta antes de usar por ejemplo tengo una tabla
donde guardo el saldo del balance de cada cuenta mensual durante los 24 meses
que tengo en programa contable, y lo tengo asi

BALANCE.DBF
----------------------
CODIGO C(12) &&almacena el codigo del plan de cuentas ej 1.01.01.01.001
APERTURA C(15) &&almacena el saldo de apertura de la cuenta "1000000.00"
MES01 C(15) &&el saldo del primer mes del periodo abierto "1000000.00"
MES02 C(15) &&..
....
MES24 C(15) &&..
Esta es una tabla principal es sumamente accedida para cualquier transaccion
que se realice lo unico que debo hacer al momento de necesitar algun valor
es VAL(MES01) y este metodo es increible como acelera el acceso a las tablas.

Para los modos de accesos a las tablas estas recomendaciones NO USEN DBC NI BUFFERS!! desconozco los manejos del VFP con estos pero no son rapidos ni
necesarios!!.

Abran las tablas con los parametros SHARED para escritura y SHARED NOUDPDATE
para solo lectura (cuando hacen reportes), usen los RLOCK() y FLOCK() para
bloquear registros y tablas.

Bueno lo dejo aca para no embarullarte mas, si quieres ahondar mas solo
postealo y te comentare mas cosas que me haya enseñado la universidad
de la vida!! o postea caracteristicas de tu BD para poder ver si estan optimizados
o no!!, Me gustaria ayudarte!!.

Gracias por las sugerencias a los 2!!!

Por un lado, ya tomé la sugerencia de es-binario de comentar este problema del programa y "abrir el paraguas" para futuros cambios.

Ahora bien. La aplicación empezó a funcionar monousuario, pero fue pensada para multiusuario, ya que siempre utilicé el sistema de buffering que bloquea/desbloquea automáticamente las tablas en forma optimista a nivel tabla o a nivel registro, según lo que el usuario necesite.

Hoy estuve con el encargado (el que tiene más idea y mi "mano derecha" en cuanto a mejorar el programa en esa empresa) e hicimos pruebas (muchas)

Llegamos a la conclusión que el problema NO es en cada terminal en particular, porque individualmente acceden RAPIDISIMO!
El problema se genera cuando 2 o más equipos acceden al programa y ni hablar si hacen algún proceso!

Yo también vengo de "Clipper" =) y lo de buffering solucionó gran parte de las cosas, pero evidentemente no lo sé utilizar (o tal vez no fue pensado con ese fin)
Sinceramente pensé que era un avance en la programación

En cuanto a las bases, hace mucho tiempo consulté (en este o en otro foro) si era conveniente 1 tabla con muchos registros o dividirla en varias tablas con menos registros. En ese momento me comentaron que "era más o menos lo mismo", ya que con los nuevos equipos, no se vería afectado el rendimiento (por el tamaño actual de la RAM, velocidad, etc). Evidentemente, tampoco sirvió.

Si conocen algún libro en la web sobre estructurar un programa, pero avanzado, se los voy a agradecer (no importa que esté en inglés)
Siempre que busco algo, encuentro lo básico: crear una base, una tabla, armar un ABM con los famosos botoncitos VCR (primer registro, proximo, ultimo registro, etc)
Ninguno habla de como mejorar la performance en redes, por ejemplo.

De todas maneras soy de las que creo que todos los días se aprende algo nuevo, así que estoy dispuesta a "mejorar" errores pasados.

Para terminar, les comento la forma en que tengo organizado el programa:

- Inicio programa y abro la base de datos
- En cada formulario, las tablas necesarias las cargo en el Entorno de Datos, de manera que se abran automáticamente cuando el usuario las necesita (si son de lectura, buffering=1 y si son de lectura/escritura, buffering=3 o 5)

Tal vez, las vistas sean una buena alterantiva para salir del paso, mientras voy armando un nuevo proyecto.

Muchas gracias!!

andrea prueba de instalar en cada terminal el ejecutable con los rumtimes de fox , y en propiedades del icono del ejecutable pon que lea en la carpeta del servidor donde estan los dbf , etc
En destino pon c:\ carpeta\tuaplicacion.exe
En iniciar en pon \\tuservidor\c\tucarpeta
Esto es una alternativa a crear un acceso directo al servidor por cada terminal de trabajo.
Yo lo uso asi con 2 terminales solamente , en tu caso son mas , y la verdad vi un cambio importante en el rendimiento.
No se es mi simple opinion , hay que probar .
Despues cuentame como fu todo.

Gracias!
Voy a probar