Programa muy lento en red

[Rafael Clemente]

Pedro:
Yo no lo he probado con FW pero sí una aplicación similar hecha con Clipper en DOS. Utilizando índices CDX. Y ahí, los browses y, en general, todos los accesos, van perfectamente. Cierto que al aplicar un filtro se retardan un poco, pero eso es razonable y, en todo caso, la respuesta en DOS es muchísimo más ágil que la que tengo ahora.
Rafael

[pymsoft]

Rafael,

Debo tambien reconocer una cosa.
(Para los que dicen que los programas en clipper eran muuucho mas rapidos)
Hay un problema y es el siguiente: Mientras con clipper haciamos ver un browse maximo de 80 columnas x 25 lineas, ahora eso aumenta de acuerdo a la resolucion utilizada, o sea, mas alta la resolucion, mas los datos que se muestran en un browse ademas de que el pintado en modo windows es mas lento que el pintado en modo texto DOS.

La unica prueba que he podido hacer con clipper y FW y xHarbour y FW, con el mismo programa, misma red, mismos archivos etc. demuestra que la version compilada con clipper es mas rapido a mostrar los datos, con las mismas caracteristicas. De hecho, uno de mis clientes no quiere usar la nueva version del programa porque dice que a pesar que tenga nuevas funciones y muchas ventajas, funciona mucho mas lento en su red, y claro... tiene razon... no he encontrado todavia una solucion a este tema.


Saludos.

[Rafael Clemente]

Pedro:
Estoy haciendo más pruebas y aquí tienes mis resultados hasta ahora:

a) He instalado un disco LACIE (320 Gb) con conexión Ethernet para contener los archivos de datos en lugar de tenerlos en uno de los PCs y la verdad es que el rendimiento mejora mucho.

b) El mayor problema lo tenía en una sección antigua de mi programa que utilizaba un LISTBOX normal y corriente; ésa sigue yendo muy lenta, incluso con el disco Ethernet. En cambio, otras funciones en las que empleo TxBrowse han mejorado mucho con el nuevo disco.

c) La respuesta con SET FILTER siguen siendo lenta, pero ha mejorado y al menos es tolerable. Desde luego, mucho mejor que con los archivos de datos en el PC principal.

d) El disco Erhernet no es muy caro y tiene la ventaja de que puede estar siempre conectado, así que no es necesario que el PC principal en el que estarían los datos esté encendido. Si no encuentro nada mejor, creo que es la solución final que adoptaré...

Rafael

[pymsoft]

Rafael,

Me alegro que al menos logres avanzar en una solución.
Yo no puedo decirle a un cliente que teniendo un servidor linux con discos scsi con redundancia, copias automaticas, etc. que si le pongo un disco ethernet todo va a funcionar mejor porque me puede asesinar
De todos modos, voy a probar tu solucion, no sabia ni siquiera que existieran los discos ethernet.
Probaré con algunas configuraciones de samba, a ver cambiando algunos parametros, como el oportunistic locking, de repente algo cambia. Porque como te dije antes, no parece ser problema en la red, porque trabajando un solo pc, vuela, con dos o mas la velocidad cambia a mucho mas lento.

Saludos y gracias por contar tus experiencias.

[A&C]

y q dicen los master al respecto.... creo q aun no han dado una explicacion claro , consisa,, y determinante,,,

y obviamente una soluion al respecto


EN ESPERA DE ALGO

BYE

[Antonio Linares]

Primero, es muy importante no usar distintas versiones de Windows en una misma red. Eso puede enlentecer mucho el rendimiento de la red.

Segundo, el gurú de los RDDs de Harbour/xHarbour es Przemek. Así que habría que preparar un ejemplo que demostrase la "lentitud" del acceso a los datos, un ejemplo en modo consola, y enviárselo para que él de su opinión

[Carlos Mora]

Rafael,

Me alegro que al menos logres avanzar en una solución.
Yo no puedo decirle a un cliente que teniendo un servidor linux con discos scsi con redundancia, copias automaticas, etc. que si le pongo un disco ethernet todo va a funcionar mejor porque me puede asesinar
De todos modos, voy a probar tu solucion, no sabia ni siquiera que existieran los discos ethernet.
Probaré con algunas configuraciones de samba, a ver cambiando algunos parametros, como el oportunistic locking, de repente algo cambia. Porque como te dije antes, no parece ser problema en la red, porque trabajando un solo pc, vuela, con dos o mas la velocidad cambia a mucho mas lento.

Saludos y gracias por contar tus experiencias.

Perdona pero... que piensas que tiene un disco Ethernet dentro? Linux! Y si, lo de la performance es una cuestion de configuración. Tamaños de paquetes, bloqueos y todas esas cosas son muy importantes en una red Samba.
La ventaja de los discos Ethernet es que usan el hardware mínimo, bajo consumo, poco mantenimiento y pocas posibilidades de que alguien que no sabe le meta mano. Si solo necesitas almacenamiento es ideal. Ahora, el hardware armado a medida suele ser mejor, y si un disco ethernet puede tener mejores prestaciones que tu servidor con discos scsi... Ojo que la redundancia tiene su precio.
Voy a suponer que los clientes del Samba son XPs. EN ese caso los parámetros que nunca se miran y te sugiero que chequees son:
OS Level: Eso determina que nivel de SO usará el Samba, es decir que SO le dirá a las estaciones que es. Si tiene un nivel bajo, digamos el de un XP, cada vez que algun equipo se une a la red SMB se produce una votación para ver quien es el que "manda", es decir quien será el Master Browser que es el que mantiene la lista de recursos del grupo de trabajo. Esa votación lleva un tiempo, y es lo que suele producir esas demoras de conexión.
Oportunistic Locking: Desabilitarlo por completo tanto en el Samba como en las estaciones. El OL implica que cuando una estación abre un archivo y nadie mas lo usa, se hace una copia cacheada de manera local para hacer la tarea más rápido. Es la forma de hacer cache de RED de una red SMB. Pero eso es lo peor cuando otra estación quiere acceder al mismo archivo, ya que el servidor tiene que requerir la atencion de la estacion que tiene el archivo bloqueado y esperar que este se lo devuelva completo con las correcciones. Esto ocaciona tambien mucha demora.
Lo mejor es desabilitar el OL del registro de los XPs. De esa manera las aplicaciones con dbfs van mucho más rápido.
De momento es lo que me acuerdo, a medida que me acuerde les posteo mas tips.

Por cierto, hay varios proyectos de SL de discos ethernet que se pueden utilizar, aunque hace bastante que no los sigo. Es cuestion de buscar en Sourceforge o Freshmeat.

Saludos,

Carlos.

[pymsoft]

Carlos,


Gracias por lo que comentas. Hoy mismo voy a hablar con quien se encarga de nuestros servidores linux para hacer las pruebas del caso. Justamente, el algo me había comentado del OL, y era una de las pruebas que haríamos esta semana, lo que me pregunto tambien, es que tenemos que desactivarlo en cada estacion con XP?, pensé que sería suficiente hacerlo en el servidor.
Le comentaré tambien el tema del OS Level.

Ya les comentaré los resultados.

Saludos

[jrestojeda]

Yo generalmente la alternativa que aplico para no utilizar set filter es crear un indice temporario y luego por medio de un SEEK() blando.

Ejemplo: oDbf:Seek(Dato1,.t.)

reduzco el tiempo notablemente del set filter y el resto lo recorro indefectiblemente de manera secuencial.

DO WHILE oDbf:Eof() .AND. oDbf:DATO<=Dato2

Mi proceso.....
...........
...........

oDbf:Skip()
ENDDO

A mi parecer esta forma no es mala y es la que más utilizo.

[Armando]

Ojeda:

Ese no es el tema, lo que estas haciendo, y creo que muy bien, es algo que sustituye a la función ORDSCOPE() no a la función DBSETFILTER() y hasta ahora el problema es con el filtrado.

Que harías si necesitas mostrar en un BROWSE solo aquellos productos que cumplan con cierta condición ?, digamos, mostrar solo los productos que dentro de su descripción tengan la palabra "DISCO"

ADAPTADOR DISCO DE 5/8-11 841
CANDADO MG-P/TA-50 LLAVE TIPO DISCO 207573
DISCO PARA CONCRETO 180 32mm
DISCO DIAMANTE 4 1/2"

Saludos

[jrestojeda]

En ese caso dentro de la parte que recorro la DBF de manera secuencial grabo una DBF temporal, la utilizo en el browse, y como ya está filtrada porque solo contiene los registros que cumplen con la condición, funciona más rápido.
Por ahora lo estamos haciendo de esa forma.
Saludos.

[Armando]

Ummmm, y si se trata de un punto de venta donde el filtrado se hace varias veces en cada venta ???

Borras, creas e indexas la DBF por cada producto ?, creo que ahí perderías mucho más tiempo.

No pretendo llevarte la contra , por el contrario, ya que me interesa el tema tambien me interesa llegar a una buena solución.

Saludos

[jrestojeda]

En ese caso tienes razón, yo me quedaría con el clásico DBSETFILTER, que si utilizamos ADS anda muy bien y rápido, el tema está en pasarle todo al DBSERFILTER como texto.
En ese caso es otras de las alternativas que utilizamos.
Está todo bien, esto es un foro, y uno no pretende que todos estén de acuerdo con lo uno dice, uno solamente trata de colaborar en la medida que puede, y me parece perfecto que opines diferente porque de esta forma, todos, día a día aprendemos un poco más
Saludos.

[pymsoft]

Armando,

Ummmm, y si se trata de un punto de venta donde el filtrado se hace varias veces en cada venta ???

Borras, creas e indexas la DBF por cada producto ?, creo que ahí perderías mucho más tiempo.

En mi caso, lo que hago es recorrer la base de datos con un dbEval (que es mucho mas rapido que hacerlo a mano) y ponerlo en un array, y luego muestro el browse del array, te aseguro que es rapidisimo.

Acabo de medir el tiempo, y en menos de un segundo busco los documentos que en el detalle contengan una cierta palabra en la descripcion, realiza las busquedas y arma el browse. (la base de detalles contiene solo 6000 registros)

Saludos.

[Armando]

Pedro:

Excelente idea, creo que hare mis pruebas.

Ya te contaré.

Saludos