General File Sharing Performance on Windows Servers

  • Thread starter Thread starter Jeff Botwood
  • Start date Start date
J

Jeff Botwood

Over the last few years, my experience with Windows Servers is that their
file sharing performance seems to be getting slower as security features are
added, bugs fixed, and security updates are released etc. The software we
write and distribute is non client-server, written in a rapid app. dev.
language called Clarion, and opens and closes files across a network drive
in the same way a DOS or WFWG based package would do, and I believe MS
Access and FoxPro also use file sharing this way. Some observations of our
software performance we have made on client's networks (usually not supplied
by us are):

NT4 servers running SP3 slow significantly after installing SP6a
Windows 2000 servers slow after promoting to domain controller
Windows 2000 servers with no SP slow after installing SP3
Sharing files on FAT32 partitions are faster than NTFS partitions, because
this bypasses NTFS security
Changing hub from 10Mb/s to 100Mb/s switch makes no difference at all !!

We always switch off oppotunistic file locking on every file server because
it causes intermitant database file corruption with our software (the same
problem affects MS Access and any DOS-based database program and has been
covered in KB articles in the past), but on messing about on a clean test
server with a stopwatch I don't think it is this that causes the performance
hit. I have tried changing hub/switches, enabling or disabling opp locks,
different service packs, and promoting to DC, and the above observations
hold. We can reproduce the same symptoms with DOS and WFWG software - our
long obsolete WFWG client management software ran faster from a P200 Win95
peer to peer server than it does now from our PIII 1GHz SBS 2000 server with
10,000rpm SCSI disk !

Several of our clients have thrown out Windows in favour of Novel, and
reported massive performance increases (e.g. 300-500% or more). We are now
seriously considering getting into Novel or Linux to investigate this
properly, which we would rather not do as we have never recommended these
systems before now and know very little about them.

Before I go this route, can anybody offer help or advice? Can recent and
fully patched Microsoft OS make a really fast file server?

Regards,

Jeff, DDS Software
 
I add to that list messing with "ACK" files and here in my LAN I group
policy off the requirement for digital signing on the SMB packets.
These are in Mariette's site www.smallbizserver.net under workstations.

Keep in mind that a domain controller will take some hits versus the
speed in saving on a member server. ...and keep in mind that we can
easily add a member file server to our networks.

Got enough cross postin' there? ;-) Advanced server and SBS aren't
going to be seeing the same issues.

Jeff said:
Over the last few years, my experience with Windows Servers is that their
file sharing performance seems to be getting slower as security features are
added, bugs fixed, and security updates are released etc. The software we
write and distribute is non client-server, written in a rapid app. dev.
language called Clarion, and opens and closes files across a network drive
in the same way a DOS or WFWG based package would do, and I believe MS
Access and FoxPro also use file sharing this way. Some observations of our
software performance we have made on client's networks (usually not supplied
by us are):

NT4 servers running SP3 slow significantly after installing SP6a
Windows 2000 servers slow after promoting to domain controller
Windows 2000 servers with no SP slow after installing SP3
Sharing files on FAT32 partitions are faster than NTFS partitions, because
this bypasses NTFS security
Changing hub from 10Mb/s to 100Mb/s switch makes no difference at all !!

We always switch off oppotunistic file locking on every file server because
it causes intermitant database file corruption with our software (the same
problem affects MS Access and any DOS-based database program and has been
covered in KB articles in the past), but on messing about on a clean test
server with a stopwatch I don't think it is this that causes the performance
hit. I have tried changing hub/switches, enabling or disabling opp locks,
different service packs, and promoting to DC, and the above observations
hold. We can reproduce the same symptoms with DOS and WFWG software - our
long obsolete WFWG client management software ran faster from a P200 Win95
peer to peer server than it does now from our PIII 1GHz SBS 2000 server with
10,000rpm SCSI disk !

Several of our clients have thrown out Windows in favour of Novel, and
reported massive performance increases (e.g. 300-500% or more). We are now
seriously considering getting into Novel or Linux to investigate this
properly, which we would rather not do as we have never recommended these
systems before now and know very little about them.

Before I go this route, can anybody offer help or advice? Can recent and
fully patched Microsoft OS make a really fast file server?

Regards,

Jeff, DDS Software

--
"Don't lose sight of security. Security is a state of being,
not a state of budget. He with the most firewalls still does
not win. Put down that honeypot and keep up to date on your
patches. Demand better security from vendors and hold them
responsible. Use what you have, and make sure you know how
to use it properly and effectively."
~Rain Forest Puppy
http://www.wiretrip.net/rfp/txt/evolution.txt
 
I had a similar experience when NT4 SP6 was released - started upgrading the
clients ahead of the servers and found that some file operations (e.g. SP6
client opening and accessing an Access MDB from a SP5 server) were
dramatically slower (instead of seconds took minutes!)

Traced it to the updated NETBT.SYS in the SP6 client - from the information
available at the time I think it was caused by a change to the 'nagling'
algorithm in this component which seems to have since been confirmed by a
throwaway comment in Q236316.

If I replaced NETBT.SYS on a SP6 client with an SP5 version then things
would whizz along as before! This change was reversed in SP6a which MS then
pushed very heavily.....

Interestingly, I seem to recall that Win9x clients had the SP6 version of
'nagling' which made me think that their performance on an NT network might
be permanently impaired

more info on Nagle algorithm in Q214397

regards
paul
 
Back
Top