DBF speed on shared drives

[wriedmann]

Hello all,
I would like to share some of our findings on speed using DBF files on shared drives because we checked the difference of speed between an array cache and the real dbf file
1) only one client on a shared drive (the file can be local, on a network drive, and can also be used more than once on the from the same client): accessing the real table using an index is faster than using an array cache
2) when the table is opened on a shared drive and another client has the file opened in read-write mode, the array access is much faster. This is true only when the speed is measured on a client, not on the server itself
3) when the table access is from the server itself, even when the session is remote desktop, or terminal server, the DBF access is faster than the array cache.

So, if you are needing speed accessing DBF files from multiple workstations, you should consider to use a terminal server. There are also low cost solutions like AADS or TSPlus that are working also with client versions of Windows (Pro versions only). We have much experience with AADS.

Wolfgang

P.S. please find attached a VO AEF of a sample program. Adapt it to your own test data. The CacheServer class is a class that we are using a lot ourselves. It shows also the speed difference between AScan() and AScanBin(). We are also working on a dictionary based X# version.

CacheServerTester.zip

(4.16 KiB) Downloaded 235 times

[OhioJoe]

Wolfgang, I concur with your findings on terminal server (currently known as RDP or Remote Desktop). Under that setup all the processing is done on the server -- no network pipe except for the screen rendering. Which probably explains the performance advantage.

One client has at least 50 login accounts and on busy days as many as 20 are logged in simultaneously. No slowdown. No problems. Every session shares the same EXE and dependencies.

We've had great success with Remote Application. Under this setup the user is logged in to the terminal server but sees ONLY the Windows app (no full desktop), which means that once loaded the app looks and feels like anything else on the local desktop.

Unfortunately Remote App isn't part of Server 16, 19 or 22. But there's a work-around:

https://github.com/kimmknight/remoteapptool

But all good things must come to an end. I've been reading that internet-facing Remote Desktop is going out of fashion because of the security concerns -- always under a "brute force" attack so we've had to restrict the IP addresses that are allowed to log in. That seems to work until a user logs in from a different location.

[wriedmann]

Hi Joe,
the only explanation I have for my findings is an aggressive caching. When the client is the only client, it can cache the file completely.
The server can always cache the file because he knows if and when a file is changed.
IMHO Microsoft is doing a lot of work on the caching algorithms, and that makes some work faster, and the other types of work that don't have advantages from this seem to be slower. And thanks to SSDs we are used now to very fast data access.
Wolfgang

[baramuse]

Very instructive and thanks for sharing !
Do you have a idea of the speed difference though ? Is it noticable enough to push for TSE/AADS ?

Regards.

[wriedmann]

Hello Baramuse,
when used by multiple users, AADS is much faster, so it could be an idea to push it.
But it works well only if the data itself also stays on the terminal server. This is our experience, but that may be different in your environment.
We have checked mainly data read for filters - indexed searches are always fast.
But a collegue of us has another approach: he creates local dbf cache files and uses them for the filters (and in fact, they are faster than array access).
At least AADS is so cheap that a check could be worth to try.
Wolfgang

[baramuse]

We'll do some tests then !

But for multi-clients installation we mostly use ADS which, I guess, fix that issue.

[wriedmann]

Hi Baramuse,
yes, ADS solves it at least partially.
Wolfgang