Christof Wollenhaupt wrote on 2014-12-19: >> >> The tables are open with multilock and opportunistic table locking. >> >> > You mean optimistic table locking, right? Because opportunistic locking is > what likely makes the first query fast. But that is an SMB thing, not a VFP > feature. > > Network access speed is largely driven by two factors: What data do I need > to read at all, and how fast can I get data across the network. For the > network speed the bandwidth is the least important attribute. More > important are latency and package throughput. > > When only one client opens a remote file, the server and the client > negotiate who is allowed to maintain the read and write caches. In most > cases this will be the client. Effectively this means that the file only > needs to be transferred once and it can be done very efficiently in large > blocks, since all the repeated small block access happens on the client. > > When a second client joins the party, the first client is being told to > send back the write cache and discard all client side caches. All further > caching is done on the server. This results in the second opening of a file > to be even slower than further requests, because the server has to wait for > the client to respond. It can also result in data loss, if the first client > fails to respond. > > The second part is package throughput. VFP will basically read every record > individually. There are optimization when repeatedly continuous records are > requested, but in many cases it's down to one record per read request. The > number of packets varies wildly between the systems. On the same network > I've seen 250 packets/sec form a Windows 7 client onto a Windows 2008 R2 > server and 1250 packets/sec from a Windows 8.1 client onto a Windows 2012 > server. But that number is still very slow compared to the roughly 30,000 > records/sec that a local drive provided. > > Process Monitor from Sysinternals is a good way to see this type of > effects. When you filter on your application, you should see a huge list of > read requests each the size of a record. There's a time column on the left. > In my cases the times where 4 ms for Windows 7 and 0.8 ms for Windows 8.1
Christof, Thank you for the thorough explanation. I am seeing exactly this. The nice thing I am seeing is the server remains fast even when multiple clients have opened the table. I'll be writing a webapi to speed up some of the common requests. Thank you, Tracy Tracy Pearson PowerChurch Software _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/000001d01b9e$6d0fd040$472f70c0$@powerchurch.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
