What is the performance and data transfer rate of NFS gateways? How does
DiskShare performance compare with competing products? These are
simple and fair questions to ask. But the answer may not be simple,
because there
are to many variables in the network configuration which
impact the performance and data transfer rate. The performance
and transfer
rate are affected by things such as:
- Reads
or Writes, they perform differently
- copying
directory trees of small files
- copying
large files or testing I/O with a program
- What
application is being used to intiate the file transfer
- The
Windows OS, Service Pack and fixes
- Amount
of memory in the Windows system
- Fragmentation,
cluster size of the Windows partition that is being accessed
- Tuning
of the Windows OS
- Network
card used in the Windows machine
- What
other Applications are running on the Windows machine
- OS
and version running on the Client
- memory
in the Client
- network
card in the Client
- Network
hardware between the Client and Server
- Network
load outside of NFS
- tuning
of the OS on the Client
- version
of the NFS modules on the Client
- NFS
tuning on the Client
- ….
This list could get much longer but you get
the idea.
NFS Performance Tests and Results
Tests are done and presented by Dr. Jack
Fegreus, Technology Director
of Strategic Communications, on the performance of a few leading NFS gateway
and CIFS products: NFS/DiskShare, NFS/SFU and CIFS/SAMBA. All
of the disk volumes that the Windows server would export via
NFS/DiskShare, NFS/SFU,
and SAMBA/CIFS
were created on a Fibre Channel nStor 4520 Storage
System. In creating the logical devices, the key was to maximize
streaming
throughput and not random access as databases are not good
candidates
for NFS. He
ran directory- and file-based read and write tests on all of the
shared
volumes. In these tests, he ran normal copy and backup operations
rather
than our optimized benchmarks to better simulate the performance
an
end user would encounter. He measured
Ethernet-based data throughput to
and from our client system and Fibre Channel-based data
throughput to and from the nStor Server System. This provided an
overall
perspective of performance at all points of the process.
NFS
throughput averaged about 48MB per second versus 25MB per second
with
Samba. This was mirrored precisely at the back end where we
were
able to measure data throughput more accurately. Equally
interesting, we observed far greater variation in instantaneous
throughput
using NFS. The highest instantaneous throughput was measured
with
NFS accessing a volume exported via DiskShare. In this case
throughput
often reached peaks of 80MB per second. Average overall
throughput
at the backend, however, was identical. Measured at the front
end
as Ethernet traffic at the client, however, SFU had a consistent 5%
advantage
in throughput. He postulate that SFU
might be gaining that very slight
advantage through its handling of the NT cache.
Go To Top 
Buy DiskShare Now
The following are some specific results based on a
few scenarios:
1.
Measure
data
throughput
performance
reading
files
and
directories at the client
server. Reading
files,
NFS demonstrated
a
2-to-1
advantage
and SFU
shares
held a 5%
edge
over DiskShare.
2.
In
addition to measuring
data
throughput
on
reads at the client,
we
measured backend
disk
throughput
for
the Windows server
coming
from the
FC
disk array. While
Ethernet-based
client
I/O
exhibited an edge for
SFU, overall backend throughput
for
DiskShare
and SFU
was
virtually identical.
3.
File
and directory
writes
proved to be
a
serious problem
for
NFS with SFU
shares.
For most of
the
data transfer
process,
directory
writes
proceeded at
a
glacial 3-to-5MB
per
second.
Conclusion
After
many tests, Dr. Jack
Fegreus concluded that for
Gigabit Ethernet server-to-server file I/O traffic between
UNIX/Linux
servers and Windows Server 2003, the performance choice
is
to put NFS on Windows rather than utilize CIFS (SAMBA).
When
it comes to putting NFS on
Windows there are then two choices: Microsoft Services for
UNIX (SFU) and DiskShare.
For
ease of installation and configuration, however, there is only one
choice.
While
we encountered no problems setting up file sharing with
DiskShare,
a number of critical issues surfaced with SFU. The problems
were
amplified by the consistent behavior to simply fail without
providing
any
feedback. In particular we encountered such incidents when
mapping
multiple Linux users to the same Windows user and when using
NIS
without a Windows domain. Equally troubling was the inability to
provide
root access while using NIS. Write
performance with NFS shares via SFU was abysmal. Writing
files was considerably slower
when using an SFU share. Writing directory
trees
often
crawled at 3MB per second.
On
the other hand, write performance using a DiskShare exported volume
was
at a par with CIFS exported volumes. More
importantly, read throughput was twice
that of the CIFS share accessed with Samba. As a result,
we were able to backup the Windows server over NFS/DiskShare mounts
without special client software at a throughput rate that rivaled the
throughput of local files.
Go To Top
Buy DiskShare Now
|
)
)
