A nosotros nos pasa exactamente lo mismo. Pero el culpable, según pude ver, es que tenemos un switch HP 1910-24G conectado a un balanceador de carga TP-LINK RT470+ (es en esencia un router que admite varios modems de banda ancha, cada uno conectado a proveedores diferentes), es decir, nosotros al router lo tenemos con dos bocas WAN, y dos bocas LAN. A una boca LAN se conecta el switch que interconecta la red interna de la organización. Si tenes algo parecido, el problema es complejo, y todo apunta a que el router no tiene capacidad de proceso o algo está haciendo mal, o bien el switch tiene una configuración que lo obliga a "trabajar demasiado" con los paquetes de red, en caso que el switch sea "administrable". 1. Se suele dar con un enrutador a internet, y un switch interno. Si el switch es configurable (administrable), puede tener el protocolo anti-bloqueo que actúa "en contra" en vez de "a favor" (spanning-tree protocol), si podés probá desactivarlo y ver que resultado tenés. Para esto, debes acceder a la página web del dispositivo, los switches administrables toman una IP del enrutador donde se conectan, o bien pueden tener una fija programada, etc. Si el switch no es configurable, entonces no queda mucho por hacer a este respecto, pero estos modelos simples no suelen tener los protocolos de anti-bloqueo como los que menciono. 2. Algunos enrutadores tienen en la(s) boca(s) LAN el control de flujo (flow-control) activado, y restringen el ancho de banda total de la boca en cuestión, empeorando la situación cuando más máquinas comienzan a colgarse del sistema. Hay que desactivar el flow-control en todas las bocas LAN del router, y definitivamente, en todas las bocas LAN del switch. Esto es particularmente importante cuando el router de internet da las direcciones IP a la LAN interna a través del switch (el router tiene el servicio DHCP, y las direcciones se distribuyen por el switch a las máquinas), y es firewall, etc. 3. Es posible que un cliente dado se conecte por LAN al switch cableado, y por WiFi a un access-point que a su vez está conectado al mismo switch, de tal manera que las IP de las maquinas cableadas se "vean" con las IP de las máquinas conectadas inalámbricamente. Puede pasar con algunas all-in-one y notebooks que tienen las dos interfaces de red y se conectan las dos por alguna razón. El problema es que en tal caso, se genera un lazo de paquetes mortal, que ralentiza significativamente algunas operaciones del segmento de red. 4. No hace falta crear un ejecutable para cada uno, pero si tener instaladas las librerías de runtime en cada máquina. Con un .BAT podes forzar el mapeo, y luego llamar a la aplicación en el volumen mapeado. Por ejemplo, si X: es el volumen de red, y \\servidor\sistema es la carpeta que tiene sistema.exe, vos podes hacer un bat que siempre reconectará aunque el mapeo se haya perdido:
Archivo sistema.bat: net use x: \\servidor\sistema cd x: sistema.exe Y el tiempo que demora en transferir el ejecutable (unos 4 MB en promedio) a la memoria de la workstation es de pocos segundos, que es el precio a pagar para tener administración centralizada del ejecutable, y no tener que copiarlo en cada workstation cuando hay un cambio. Recordemos que la carperta \\servidor\sistema debe tener los permisos de cada usuario de la red, lectura y escritura. Exitos Carlos A. Pérez El 19 de noviembre de 2016, 14:52, Claudio Villarreal<[email protected]> escribió: > Hola Jose > La verdad eso es lo estoy viendo. Tengo un sistema en otra empresa cuya > base de datos principal de clientes tiene 150000 registros y algunas de las > tablas crecen de 40000 registros por mes durante los 12 meses del año. A > pesar de esto las 5 o 6 PCs trabajan bien. > Veo que vos trabajas con tablas libres. Yo trabajo con una base de datos. > Podrá ser eso? El sistema esta instalado en una de las PC y creo una unidad > de Red donde accede cada usuario al mismo ejecutable. Tendre que crear un > exe para cada uno? > Desde ya muchas gracias. > Saludos > > Claudio > > El 8 de noviembre de 2016, 23:02, Jose Paez<[email protected]> > escribió: > >> Hola Claudio >> >> >> Adjunto una impresión del tamaño de las tablas libres con que trabajo >> desde VFP (Formularios, Grids, Reportes), accedidas concurrentemente desde >> unas 80 PCs (aproximadamente) y los tiempos de acceso aceptables. >> >> >> Es muy probable que tengas un problema de red. >> >> >> >> >> Saludos >> >> José Paez >> ------------------------------ >> *De:* [email protected] <[email protected]> en nombre de Claudio Villarreal < >> [email protected]> >> *Enviado:* martes, 8 de noviembre de 2016 05:37 p. m. >> *Para:* GUFA List Member >> *Asunto:* [GUFA] Form lento >> >> Hola Colisteros >> Tengo un problema con un form el cual les paso a detallar. >> En un sistema de una clínica tengo instalado el sistemas en 2 PC (win XP >> y Seven). El sistema esta instalado en unas de la PC, la cual hace las >> veces de servidor. Las tablas (Nativas de FOX) las abro con AGAIN y ALIAS >> en cada vez que se abre el form. El problema es que cuando se abre el form >> de AMB de Turnos en una de la PC servidor esta funciona bien y el medico >> abre su agenda en la otra PC, la agenda se vuelve muy lenta en todo (cuando >> se abre el form, cuando actualiza las vistas, cuando sale de la atención >> del paciente y vuelve a la agenda, etc.). Pase el sistema a la PC del >> medico, la cual es mas nueva, y el problema sigue, pero al contrario, la >> agenda del medico funciona bien y el ABM de Turnos se pone lento. >> Si paso el sistema a una tercera PC se ponen lentos los dos forms. >> Alguna idea de como solucionarlo? Necesitare un server? O tendre >> que migrar todo a SQL ? >> Desde ya muchas gracias >> >> Claudio >> >> > -- Ing. Carlos Alejandro Pérez
