Why does the NT Network Performance Pack reduce "performance"? (AREV Specific)
At 01 SEP 2004 10:08:57PM Kennis wrote:
Upgrading a client's AREV 2.01 system to 2.12 and adding the NT Service Pack has increased the I/O time enormously. A job that took 5 seconds is now around 2 minutes. Other jobs that require a lot of I/O are similar.
I did some research and easily duplicated the problem at our site. Locking and unlocking took no time at all but reads and - especially - writes took much, much longer. I found that commenting out the locking statements cut the time to 30 seconds, which means that it takes more to both read and write records that are locked than records that are not locked.
The default "exclusive record" lock was used.
One file was read and updated. Using data from that record, the key to a record in another file was derived and that was read and updated.
The processing in both cases was lock, read, update, unlock.
One field updated in the first file was related to another file. No other indexing was involved, but in AREV 2.03 they dumped the
!INDEXING file so that should be little different, and in any case the slower response occurred with both files. I don't believe that indexing is a cause of the problem.
I have checked the server settings. The server runs NT 4, SP6. Stations are Win 98 SE.
It is now set to "Maximize Throughput for File Sharing" instead of "Maximize Throughput for Network Applications" and it made no difference. We run with NetBEUI.
The server was set to FILES=20 in CONFIG.NT. I brought down all the stations. I changed it to FILES=200. I stopped, removed and recreated the Service. I downed and rebooted the server. I rebooted the stations. It made no difference.
The test stations (I used 2 different models) had empty CONFIG.SYS's. I added FILES=200 and rebooted. It made no difference.
The call to AREV.EXE has the parms /X /M4096. The Properties memory has Expanded Memory of 4096 and Extended Memory of None.
The ALL-NETWORKS driver is installed.
I take it that "performance" means reliability, not speed. I note that it runs faster when running programs but in this case the job is "I/O-bound", not "CPU-bound" and it runs like a foot-sore snail.
Ideas anyone?
Ps. Thanks for all the other tips that I picked up and tried.
At 03 SEP 2004 11:26PM Steve Smith wrote:
]] Stations are Win 98 SE
Have you tried adjusting the write-behind caching on SE? This may introduce lags which cause contention.