Newsgroup: it.comp.lang.vo-clipper
Titolo: apertura file shared in clipper

Ciao a tutti. Perdonatemi  ................ qualcuno che ha tanta pazienza
può aiutarmi?
Da sempre ho avuto questo problemino: una volta aperto un file in shared
mode (residente su un server) tutte le operazione di scrittura/lettura sul
suddetto file sono di gran lunga rallentate.
Come ho sempre risolto? Con uno modo che non fa tanto onore alla
programmazione: mi apro il file in modo esclusivo quando proprio non ne
posso fare a meno! allego un esempio che mi rallenta moltissimo le ricerche
anagrafiche (sono circa 12000 rek).
use anart index acodi exclusive    -------- oppure ---------     shared
wkey="3436" (esempio)
do while .not. eof()
   If  wkey $upper(nomecampofileanart)
       ? "trovato"
   endif
   skip
enddo
se lo apro exclusive su 12000 rek ci sta 0.45 secondi se shared 7 secondi!
Dove sbaglio? Grazie comunque a tutti e buon lavoro.

 Dove sbaglio?
Se usi gli NTX prova ad utilizzare Comix (con Clipper 5.2e) oppure
DBFCDX (con Clipper 5.3b). Versioni più vecchie di Clipper potrebbero
avere dei problemi.
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg

 Dove sbaglio? Grazie comunque a tutti e buon lavoro.
:-((( sono su c6 come demonfly dalle 20 alle 23, ti spiego in chat
altrimenti e' lungaaaaa ;-)
--
Alessandro Maiucchi
maiu...@libero.it
http://maiucchi.supereva.it
(Basta!-Scrittura creativa-Rush-Queen-Kiss-Blade Runner)

enddo
Per quello che deduco dall'esempio, la tua ricerca può essere svolta
un po' più velocemente senza bisogno dell'indice (cerchi un campo che
contenga al suo interno una data stringa), seguendo l'ordine naturale
di sequenza dei record.
C'è da dire che se cerchi una sola occorrenza, dopo il ? "trovato" ci
starebbe bene un exit...
Se poi vuoi ottenere risultati più efficienti, devi pensare alla
possibilità di un qualche indice, o artifizio, opportunamente
studiato.
Per quanto riguarda la modalità di apertura del file residente sul
server, è ovviamente preferibile (per l'operatività degli utenti) che
essa sia shared, per cui, se non puoi usare indici adeguati, potresti
valutare se non sia conveniente copiarti in locale tutto il file per
poi effettuare sulla copia le ricerche in modo esclusivo.
ciao

 eeeeh? e l'indice? a questo punto fai prima con un indice condizionale...
Verissimo. Anche solo chiudendo l'indice dovrebbe notare un incremento
considerevole di velocità in quanto scorrere un DBF con l'indice aperto
è molto più lento che scorrerlo con tutti gli indici chiusi (nel primo
caso il sistema deve andare a cercare il record prima nel file indice e
poi, trovatolo, nel file DBF).


Intanto grazie a tutti.
Ho provato con  un' indice condizionale:
ci sta 1.2 sek a crearlo e pratic. nulla a scorrere il file. L' unico
problema potrebbe essere un problema di sincronia con il databases dato che
l' indice che creo per la ricerca è locale e nel frattempo sul database
possono essere effettuate modifiche, ma questa eventualità può essere
procedurizzata.
Marina
Lavoro per una società di informatica (non dico assolutamente il nome per
non fare spam). Per qualsiasi problema (se posso renderVi l'aiuto) sono a
Vs. disposizione. Grazie ancora.

 un rallentamento.
è normale in quanto il client di rete (il cosiddetto redirector, VREDIR.VXD in 
Windows 9x se si accede una rete Windows) riesce a bufferizzare un file che è 
aperto da una sola postazione oppure in esclusiva, invece deve eseguire 
immediatamente tutte le scritture nel caso di un file condiviso.
Saluti
Wolfgang
Merano

 immediatamente tutte le scritture nel caso di un file condiviso.
A me questo proprio non risulta. Mi risulta invece che le cache lavorino
benissimo anche in rete con file condivisi. Altrimenti a cosa servirebbe
il COMMIT?


un rallentamento.
Possono capitare casi particolari, ad esempio utilizzando massivamente
la dbseek(), magari da piu' postazioni.  Bisogna tenere presente che
in questo caso Clipper effettua operazioni di lock/unlock in maniera
trasparente sugli indici.
ciao, acc.   
a...@libero.it

 trasparente sugli indici.
Ah, sì, in questi casi certamente. Ma a me pareva che venissero rilevati
rallentamenti anche con un solo utente a lavorare e questo mi pareva
strano. Ho capito male? Comunque credo che il tempo necessario a fare il
lock/unlock degli indici sia completamente trascurabile.


 il COMMIT?
il commit() no Ti garantisce che i dati siano scritti sul disco finchè il file è 
aperto in esclusiva oppure da una stazione soltanto.
Questo è giusto sia per il client Novell che per quello Windows.
Saluti
Wolfgang
Merano


Sono sicuro di aver letto tante volte che le cache lavorano anche con
file condivisi e non mi sembra possibile che le scritture, in quel caso,
siano sempre dirette. Sei sicuro di quello che dici? Vogliamo sentire
cosa ne pensano gli altri?


lock/unlock degli indici sia completamente trascurabile.
Dipende anche dall'hardware oltre che dal carico, comunque su un
server ben configurato non ci sono problemi.
Per quanto mi riguarda Clipper e' molto veloce nella gestione della
rete.
ciao, acc.   
a...@libero.it

 cosa ne pensano gli altri?
Credo abbia ragione stia in mezzo .
In effetti i record appena scritti o aggiornati sono sempre disponibili
immediatamente anche
da altre postazioni con qualsiasi tipologia di rete (DOS o Win).
Credo invece sia la chache che lavora in mondo differente , il record prima
di essere cercato
direttamente su disco è prima cercato nella cache con il risultato di
aumentare le prestazioni del
disco questo indipendentemente dalla commit o da siutuazioni di multiutenza.
Difatti se spegni il Server senza svuotare le cache su disco perdi dati ,
pur se questi dati sono già
stati resi visibili dalla rete o da una comit a tutti.
Che io sappia la commit forza semplicemente la scrittura fisica dalla cache
al disco .
Io ho sempre inteso un meccanisco del genere.
ciao Alessandro.

 al disco .
Infatti. Non vedo cos'altro potrebbe fare. Solo, penso (ho letto, se non
ricordo male) che la garanzia totale della scrittura effettiva non c'è
neanche con il COMMIT (almeno in rete).


 neanche con il COMMIT (almeno in rete).
Io non ho mai riscontrato problemi , forse semplicemente non li ho notati in
quanto molto rari .
Ciao e buon lavoro.
Alessandro.


Be', il fatto che la COMMIT non possa garantire la scrittura effettiva
(ammesso che sia vero) non è un problema in sé. L'importante è che il
sistema possa garantire che il contenuto della cache venga, prima o poi,
scritto sul disco, sperabilmente prima che venga perso. :-)


 siano sempre dirette. 
allora devi distinguere tra la cache sul lato client e sul lato server. Ovviamente 
con file condivisi il caching sul lato client è impossibile, mentre quello sul lato 
server è usabile.
Purtroppo la cache sul lato client ha una maggiore efficacia della cache sul server 
in quanto i dati non viaggiano immediatamente sulla rete.
Saluti
Wolfgang
Merano

 in quanto i dati non viaggiano immediatamente sulla rete.
Questa frase mi è oscura...


cosa ne pensano gli altri?
Una operazione di flush effettuata da parte di un client su di un file
remoto garantisce soltanto che i dati sono arrivati al server, se poi
il server implementa una cache in scrittura sono affari suoi.
Una volta che il server ha confermato la ricezione dei dati il client
e' libero, non e' garantito che i dati siano stati fisicamente scritti
sul supporto.
Questo almeno per quanto riguarda windows.
ciao, acc.   
a...@libero.it

in quanto i dati non viaggiano immediatamente sulla rete.
Ok, ma in caso di file condivisi una cache sul client non ha senso.
ciao, acc.   
a...@libero.it

 Questo almeno per quanto riguarda windows.
Il che è esattamente quello che sapevo anch'io. Credo proprio che sia
Wolfgang (spero di aver azzeccato il nome) a confondersi.


 Ok, ma in caso di file condivisi una cache sul client non ha senso.
in effetti, e questo spiega il calo immediato delle prestazioni se un file viene aperto 
da un altro client. Il server segnala poi al client: non sei più l´unico a usare questo 
file - regolati, e il client deve comportarsi in maniera differente. Il server _non_ 
cambia il suo metodo, perchè ovviamente la sua cache serve tutti i client.
Il bug nel redirector del Win95B e C (VRedir.VXD versione 1111) era proprio un errore 
in questa strategia: quando un altro client aggiungeva un nuovo record, il client non 
rinfrescava la sua informazione prima di scrivere un record nuovo lui stesso. Questo 
spiega anche perchè non succedeva con reti Novell: quelli usano un altro redirector. 
Che si trattava di un bug sul client viene poi confermato dal fatto che accadeva con 
tutti i server: Win9x, WinNT, Win2K ecc.
Saluti
Wolfgang
Merano

 Questa frase mi č oscura...
la cache sul server serve a "velocizzare" l´accesso fisico ai dischi, ma comunque č 
sempre subordinato al passaggio dei dati sulla rete. La cache sul lato client č molto 
piů efficace in quanto _non_ fa passare i dati sulla rete, ma funziona solo con file a 
solo lettura oppure non condivisi.
Saluti
Wolfgang
Merano

 Wolfgang (spero di aver azzeccato il nome) a confondersi.
il nome lo hai azzeccato. Il suddetto č giusto se lasci fuori dal gioco la 
cache sul client. Se torniamo al DOS con il vecchio client Novell che doveva 
occupare meno di 110k di memoria, questa cache era semplicemente non 
possibile.
Quando ho poi installato il Client32 per DOS sulla mia macchina, la maggior 
parte della applicazioni di rete ci ha messo il turbo - sono diventati molto 
piů veloci - per un motivo molto semplice: c´era spazio per 4 MB di cache in 
locale (che era possibile anche impostare manualmente, ma nella documentazione 
c`era scritto che mettendo a 0 questa cache si ritornava alle performance di 
un client DOS vecchio.
In un sistema moderno abbiamo dei cache in cascata:
- la cache del network redirector locale
- la cache del sistema operativo di rete
- una eventuale cache sul controller del disco (normale per i RAID)
- la cache fisica sul disco
Tutti questi sono presenti per aumentare le prestazioni e normalmente non si 
lasciano commandare da una richiesta di flush da parte del programma, perchč 
quest´ultima viene anche fatta in caso di chiusura del file. Sui client poi č 
impostabile normalmente dopo quanto tempo dopo il flush il client deve 
scrivere effettivamente sul server. In Novell, questo parametro si chiamava 
true commit = on, ma si sconsigliava da parte di Novell di farlo.
(ho fatto parecchi anni l´amministratore di rete di una rete Novell, ma qua si 
tratta di tecnologie usate in tutte le reti e tutti i sistemi operativi)
Saluti
Wolfgang
Merano

 Questo almeno per quanto riguarda windows.
Te lo posso confermare anche per i server Novell e per i server Unix/Linux 
con Samba. 
Saluti
Wolfgang
Merano


Dunque: tu avevi detto che le scritture su disco in un sistema a rete
locale e archivi condivisi erano tutte dirette, senza cache. Io dicevo
che questo non mi sembrava possibile. Mi sembra che siamo arrivati alla
conclusione che avevo ragione io, o no?


 da un altro client.
Quale calo immediato? Non mi risulta proprio che basti aprire un file
condiviso per vedere un rallentamento delle operazioni. Se parliamo di
lettura/scrittura dei record allora ok, ma quello è un normale problema
di traffico sulla rete.


 cache sul client.
Forse è stato questo il fraintendimento fin dall'inizio. Tu pensavi che
io parlassi di cache in scrittura sul client mentre io davo per scontato
quella sul server. Ci siamo?



Vedi, quindi, che la cache in scrittura funziona benissimo anche con
file condivisi?


 problema potrebbe essere un problema di sincronia [...]
Basta aprire tutti gli indici e lasciare quello come principale...
--
Alessandro Maiucchi
maiu...@libero.it
http://maiucchi.supereva.it
(Basta!-Scrittura creativa-Rush-Queen-Kiss-Blade Runner)

 locale e archivi condivisi erano tutte dirette, senza cache. 
no, assolutamente no. Dicevo che la cache locale del client veniva esclusa, non quella del 
server. Ma visto che la cache sul lato client era più efficace, si doveva notare un 
abbassamento delle prestazioni.
Saluti
Wolfgang
Merano

 di traffico sulla rete.
se un client ha aperto un file in lettura/scrittura condivisa, ma č l´unico ad averlo 
aperto, l´accesso č molto veloce, in quanto le scritture vengono bufferizzate sul lato 
client. nel momento in cui un altro client apre lo stesso file, le scritture devono essere 
passate immediatamente al server, perciň la cache di scrittura sul lato client viene 
esclusa, e le prestazioni in scrittura si abbassano.
Saluti
Wolfgang
Merano

 quella sul server. Ci siamo?
si
Wolfgang
Merano

 abbassamento delle prestazioni.
Invece di questo non ne sono molto convinto. Per quale motivo la cache
sul client dovrebbe essere più efficace? Se il server è potente e la
rete veloce credo proprio che la differenza non sia significativa.


 rete veloce credo proprio che la differenza non sia significativa.
non dirai mica che secondo te l´accesso alla cache locale (la RAM della macchina client 
stessa) non è molto più veloce che l´accesso alla cache del server tramite la rete, dove i 
dati non devono solo passare prima il bus PCI (_molto_ più lento dell´accesso alla RAM), poi 
la rete a 100 MBit, di nuovo il bus PCI del server fino a raggiungere la RAM del server?
Saluti 
Wolfgang
Merano

 la rete a 100 MBit, di nuovo il bus PCI del server fino a raggiungere la RAM del server?
No, certo, sulla carta dovrebbe essere così. Ma il mio dubbio è che, nei
casi reali, la differenza sia, appunto, apprezzabile. Dovrei fare delle
prove ma purtroppo non ho una rete sotto mano... :-(
