Ver la versión completa : Sistema en visual Basic
que tal amigos
en esta ocasion quiero molestarlos con lo siguiente: en la empresa donde estoy, hay una aplicacion creada en visual basic, que pesa aproximadamente 15 Mb. todos los usuarios se conectan a la misma aplicacion que esta en el servidor, pero a veces esta muy lento.
y me pidieron mejorar esto, a lo que se me ocurre departamentalizar, o sea, separar todos los formularios que Utiliza el departamento de ventas y asi sucesivamente con los demas departamentos: que me aconsejais?
espero no os molesteis si veis este mismo post en otro foro, pero la verdad es que me urge solucionarlo
saludos
Lo mas importante sería detectar en donde se está localizando el bottle-neck del sistema.
Si está hecho en vb6 o alguna versión anterior es mas que seguro que no hay multiprocesamiento por hilos ni nada similar, por lo que cada peticion a la aplicación servidora podría estar malgastando valioso tiempo del procesador en esperas propias de las transacciones. Lo mejor en este caso sería aportar capacidad de multiproceso al sistema, pero para esto habría que rediseñar la aplicación y preferiblemente usar un lenguaje que brinde mas posibilidades de procesamiento en paralelo.
Supongo que con "a lo que se me ocurre departamentalizar, o sea, separar todos los formularios que Utiliza el departamento de ventas y asi sucesivamente con los demas departamentos" te referís a crear una aplicación por cada departamento.
En este caso, si bien es cierto que aliviaría un poco la sensación de lentitud, tampoco debería ser mucho, salvo que haya una gran cantidad de departamentos y que todos tengan una baja carga individual.
Saludos
¿No sería mas facil instalar la aplicación en cada ordenador y que se conecten a una base de datos en el servidor? Se supone que un server tiene que aguantar muchas conexiones simultáneas pero, ¿de cuantas conexiones estamos hablando?
Lo que ocupe el programa (los 15MB que dices), no influyen en cuanto a "velocidad de ejecución".
Aunque se fragmente la carga del lado del cliente (muy bien pensado por aquello del "divide y vencerás"), el servidor seguiría siendo el cuello de botella al atender múltiples transacciones (por mucha máquina sea, potencia que tenga y ancho de banda disponible). Estoy con Marchi, lo mejor es buscar un SGBD que tenga un buen método de control de concurrencia (mysql, oracle, postgresql, etc.), y en la aplicación del lado del cliente crear planes de ejecución para establecer los puntos de sincronismo adecuadamente.
De todas maneras, si no dices que es lo que hay, no podemos hacer gran cosa... Ya que normalmente cambiar de servidor, de SGBD, o retocar la aplicación, es decir, llevar a cabo cualquier plan de migración, cuando ya se encuentra todo el sistema en producción suele ser muy costoso (Suponiendo aún así que el Area usuaria no tenga que invertir en formación para adaptarse a nuevos cambios...).
Un saludo.