Networking ACCPAC Plus

[scottyv]

Testing VDos to run Accpac Plus Accounting (Networked) on 64bit clients. Installs easily, performs fine.

When we add more Vdos users to the network (one instance per user) it seems to slow down for each user.

When only one user is on the network it's lightning fast and each client machine is not getting overloaded individually.

Not running any antivirus locally or on the newtwork.

Any thoughts on what is causing this behavior?

[Jos]

Shouldn’t happen of course, certainly when the users have their own workstation.

Some software add logic to the record locking mechanism to for instance keep track what workstation locks some data. The workstations get a name, commonly by setting a environment variable. This is done as it was before?

Eventually run Process Monitor (https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) at one workstation and inspect what the (suspected) extra network traffic is about.

Perhaps all are fighting for exclusive access to the same part of a central control file.

Jos

[scottyv]

Yes, most likely a file share or locking issue. The original software from Accpac had a windows system manager installed (and still is) on server

When windows 2000 and above clients were used (software predates this) you had to modify the windows registry for clients and server for lanman server and lanman workstation to turn
off opportunistic locking to prevent issues.

For safety I disabled this on my 64bit clients too. Could this have anything to do with it perhaps?? I did have one instance of vdos plus say it could not access a swap file (which are kept
on the server) but not with regular vdos.

I will investigate traffic and see what comes of it. Thank-you very Jos for your input

[Jos]

I don’t know what that Windows system manager is about. It is something like the Btrieve/Pervasive database manager?

Essentially you should leave opportunistic locking alone, it’s supposed to be transparent to applications that don’t explicitly use that.

Swap files in the sense of memory swapping are private to a program.
So it is best to keep them local. Though memory swapping shouldn’t occur that frequent to have a big impact on performance.

Jos

[scottyv]

Installing Plus Printing DOS on Win 2000.doc (1013 KB)

[scottyv]

Hi Jos, The above link is the original documentation for running ACCPAC (a dos accounting program) in a windows environment on 2000 and up Windows.

Currently, we are using ntvdm along with tamedos and this has allowed us to run ACCCPAC on 32bit Windows including Windows 10 very well with no sharing or slowdown issues.

All the current clients have the reg mod (and always have) for opportunistic locking

[Jos]

The problems with opportunistic locking seems exclusively related to Windows NT and 2000.

I found 5 who registered vDos in the past and mentioned ACCPAC, 2 added the Plus. 4 did a network registration, 1 registered 4 user names.
Strangely (?) the only question that came of these 5 was one who didn’t know how to set the vDos window size.

So although ACCPAC will be used by at least the 5 mentioning that, I have virtually no knowledge about it.

To ACCPAC getting slower with an increasing number of users:
While an user might think being real busy/demanding, he/she mostly isn’t in perspective to network traffic.
If you however tested with a time consuming task like a complex report, running simultaneously at the workstations, then that could very well lead to traffic jam or the server not keeping up with file operation requests.

Jos

[scottyv]

We run about 10 client machines with the ACCPAC Accounting Software. Most are running order entry and AR software and I have vdos on about 5 of them. The rest run ntvdm on 32 bit and they are fast no matter what load (does not affect them).

For starters, I first tried moving the swap file folder to each of the clients drives vs the server drive.  Seemed faster initially but as we got busier it slowed.

The speed issue is not when executing command, prints, etc. it's when starting up and when moving from one module startup to another.

That's why I started with moving the swap file because it was written to the server on each startup session.

Then I tried moving everything including the startup programs and modules to each of the local client drives and it actually got slower.
Originally everything was called from the server, program software and shared data.

I also had a friend run a sniffer on the network and there did not appear to be any issues as well. He was also talking about protocols, smb1 & 2 as well

I am only running 64bit on a couple clients and 32bit on the rest and they all perform about the same with vdos. 

Both 64bits have ssds but they are older. I have 2 new Dell 64bit high end machines coming so I will test with the latest and see 
if a better CPU and new NVE SSD drives (super fast  transfer) helps. I kinda doubt it,  but we will see.

The server we are using is old, 32 bit (Server 2003, lol) but it has sata drives and it was never a bottleneck for serving files.

We have a newer 64bit server already loaded up to try as well but one thing at a time.

[Jos]

I cannot come up with an explanation why the ACCPAC performance would degrade.

You could:

1. Have a look at Windows Task Manager, the CPU usage dropping dramatically at switching modules. If so, add the undocumented IDLELOW directive to config.txt. Something like IDLELOW = 100000, this will postpone vDos going to sleep (and so execute ACCPAC at a very low speed).
2. Start vDos with the log option (….vDos.exe /log), and look in the generated vDos.log file for ‘weird’ things going on at switching modules. Files not found, locked, hiccups and the like.
3. Use Process Monitor to detect extraordinary file operations at switching modules.

Jos

[scottyv]

Jos,

Tested old server with dos box-x, same exact issues.

Installed new 64 bit server over the weekend.

File transfer speeds test at twice the old servers speed. This could help. 

And from the small tests I ran already it seems better.

Will have enough traffic and users today to test real world scenarios.

[Jos]

I’m afraid that twice as before speed doesn’t actually solve, is even related to the issue.

The vDos log file foremost reports exceptional things going on, but could reveal why the time switching modules increases.
Perhaps some undefined Windows path that takes a long time to resolve (return an error condition).

Jos