Newsgroup: it.comp.reti.locali
Titolo: Access lento su rete WiFi

Un cliente ha fatto un programma in Access (2010 mi par di ricordare). 
E' composto da due file separati, uno contenente maschere, query, 
ecc... e l'altro con le sole tabelle, collegate al primo.
 
Del primo file c'è una copia su ogni pc degli utilizzatori, in quando 
devono vedere maschere diverse, mentre il secondo è ovviamente un file 
unico, centralizzato, che in un primo momento risiedeva su uno dei PC 
che funge da server.
 
Il file "dati" ha una dimensione di circa 200 MB
 
Da qualche settimana riscontrano (saltuariamente) una forte lentezza 
delle risposte dai client connessi via WiFi (da quando è stato 
installato un nuovo router con WiFi, le cose hanno funzionato 
regolarmente per mesi), ma solo per ciò che riguarda quel programma. 
Tenendo conto che tali client si connettono alla WiFi ad una velocità 
(dichiarata) di circa 72 MB e quelli connessi in rete cablata vanno 
comunque "solo" a 100 MB, non mi spiego perché nel primo caso si 
presentano tali blocchi mentre nel secondo va tutto liscio.
 
Non ci sono interferenze di altre reti WiFi nei dintorni, e ho provato 
a vedere se vi fossero apparati tipo centraline telefoniche e cordless 
che potessero disturbare ma la mia ha potuto essere solo una prova 
empirica (non sono attrezzato come Capitan Ventosa per scovare 
interferenze radio) che non ha dato risultati apprezzabili in quanto, 
anche quando il programma va in blocco, riesco comunque a raggiungere 
le risorse condivise dell'altro PC e a movimentare file a velocità 
ragionevoli
 
Come ultima prova, ho collegato tutti i pc interessati ed il router 
WiFi ad uno switch Gigabit ma ovviamente i client WiFi si collegano 
sempre a 72 e cambia poco o niente.
 
Cosa'altro posso provare?

 Cosa'altro posso provare?
più che altro devi fare una divisione.... 72 Mbit/s per un wifi vanno 
letti alla metà circa in quanto il traffico non è full duplex e quindi 
la massima capacità di trasferimento di una connessione wifi di questio 
tipo dovrebbe essere intorno ai 36 Mbit/sec.
Questo valore dividilo per il numero dei dispositivi connessi (inclusi 
smartphone ed altri dispositivi che utilizzano il segnale wifi) ed avrai 
la massima velocità possibile sulla rete...

meddix on UbuWIN ha spiegato il 19/03/2018 :

Ok, ma abbiamo fatto una prova questa domenica, proprio per evitare che 
ci fossero altri dispositivi connessi. Anche con un solo pc connesso, 
spesso e volentieri il database rispondeva dopo 5-10 secondi, mentre 
via LAN era istantaneo. Il router ha una WiFi 802.11 b/g/n quindi in 
linea teorica dovrebbe reggere fino a 300 Mbps, quindi i 72 Mbps sono 
quelli raggiungibili dai pc connessi, che comunque sono solo 3 (altri 3 
sono pc fissi connessi via LAN). Vuoi dire che 3 pc connessi ad una 
WiFi di quel tipo, possono incontrare un tale collo di bottiglia?



Il collo di bottiglia di un'applicazione del genere è l'uso di un
database che non è un vero client-server; in breve tutti i client
accedono al DB condiviso tramite una share di rete (\\xxx\y\db.mdb) ed
il "motore" di gestione del DB risiede su ciascun client, questo a sua
volta significa che una qualsiasi interrogazione del DB comporta un tot
di traffico tra il "motore" (che gira sul client) ed i dati (che
risiedono sul server); una prima ottimizzazione nel caso di
applicazioni come quella che hai, sarebbe installare sul "server" una
copia di SQL  Express, spostare tabelle/viste/... su SQL ed a questo
punto modificare il db "dati" (access) in modo che contenga soltanto
oggetti linkati; a questo punto il db "dati" (ma che in effetti sarà
vuoto) risiederà localmente sui vari clients e le query inviate sulla
rete saranno minimizzate anche perchè le letture necessarie alla loro
elaborazione verranno eseguite sul server dove gira il motore del DB
 
Certo che, nel 2018, sentire ancora parlare di applicazioni presentate
(del tutto incorrettamente) come "client-server" e basate su DB access
e share di rete, fa venir voglia di mettersi le mani nei capelli
 
 
 
 
 
 
 
 

 e share di rete, fa venir voglia di mettersi le mani nei capelli
 
e questo è chiaro e condivisibile, direi di accettarlo e non parlarne 
più, l'op obietta che solo via wireless ci sia un problema,



Ad occhio credo si tratti semplicemente della mole di dati che viaggia
sulla rete ad ogni interrogazione (o richiesta dati), se nel caso della
rete cablata, la velocità della stessa "nasconde" tale problema, nel
caso della WiFi, il problema emerge piuttosto chiaramente
 
 
 
 

 chiaramente
 
tra l'altro, un test relativamente semplice potrebbe essere quello di
far girare uno sniffer sul client, e controllare sia la mole di dati
che transita durante le operazioni, sia i tempi di risposta ed il
numero di pacchetti su WiFi e su rete cablata e poi confrontare tali
dati
 
 
 

 e share di rete, fa venir voglia di mettersi le mani nei capelli
 
Guarda, io posso anche essere d'accordo su questo, ma parliamo di un 
programmino autoprodotto (che poi ovviamente col tempo si è espanso). 
Già l'idea di migrare la parte dati su SQL la vedo difficile (per 
loro), comunque mi faccio dare una copia del DB e faccio delle prove.
Per il momento dovranno limitarsi ad usare la rete LAN

 loro), comunque mi faccio dare una copia del DB e faccio delle prove.
 
Guarda che non è una gran complicazione, specie considerando il ridotto
numero di client; la prima cosa da fare è installare SQL Express (che
tra l'altro è gratuito), poi potresti usare questo tool per verificare
eventuali problemi e migrare i dati dal DB Access ad SQL
 
https://docs.microsoft.com/en-us/sql/ssma/access/sql-server-migration-assistant-for-access-accesstosql
 
 
poi potrai valutare se modificare il codice applicativo in modo da fare
accesso diretto ad SQL Server (invece di usare il DB Access) oppure se
trasformare gli oggetti del DB Access in oggetti collegati (es. linked
tables); ovviamente il primo approccio garantirà migliori prestazioni
a fronte di alcune modifiche al codice (apertura DB), mentre il secondo
richiederà modifiche minime (o nulle) al codice ma fornirà prestazioni
inferiori (dato il doppio passaggio DB access ->  DB sql) anche se
sicuramente migliori di quelle attuali
 
 

 sicuramente migliori di quelle attuali
 
Se le modifiche da fare alla parte front-end sono solo relative al link 
delle tabelle collegate, sarà sicuramente fattibile la prima soluzione



Se converti le tabelle in tabelle collegate, le modifiche si dovrebbero
fermare a quello, se invece decidi di migrare tutto su SQL senza avere
il DB Access "intermedio", allora la faccenda potrebbe essere un
pochino più complessa dato che dovrai rivedere anche il codice relativo
alle viste e, soprattutto, i reports; nulla di impossibile ma
ovviamente richiederà più tempo, anche se il risultato sarà migliore,
specie in termini di prestazioni
 
 
 
 
 

 specie in termini di prestazioni
 
Il programma non l'ho fatto io e, per quanto sono arrugginito, non 
metterei mai le mani in quel programma per fare modifiche al codice.
Comunque mi farò mandare il tutto e farò delle prove

 collegate al back-end. Cosa cambierebbe con un DB intermedio?  
 
in tal caso, ti basterà cambiare il linking delle tabelle facendole
puntare a quelle residenti su SQL server; in /teoria/ con una config
del genere, la migrazione dovrebbe essere anche più semplice; l'unica
cosa che dovrai fare, nel caso tu decida di utilizzare dei DSN (ODBC)
per il linking, sarà creare un DSN con lo stesso nome su tutti i vari
client
 
 

 client
 
Se fosse così, me la caverei con poco.
Grazie



beh, se riesci ad ottenere una copia dei DB (app e dati), credo non
dovresti aver problemi nel tirarti su un'istanza locale di SQL express,
copiare i dati dal db "dati" in SQL express, modificare il DB "app" in
modo da linkare le tabelle su SQL e poi fare qualche test in modo da
verificare se vi siano problemi