home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / clients / 258 < prev    next >
Encoding:
Internet Message Format  |  1993-01-06  |  1.3 KB
  1. Path: sparky!uunet!olivea!spool.mu.edu!uwm.edu!ogicse!news.u.washington.edu!tad
  2. From: tad@wrq.com (Tad Marshall)
  3. Newsgroups: comp.client-server
  4. Subject: Re: NFS and RPC
  5. Keywords: NFS,RPC
  6. Message-ID: <1ig6ltINNe2d@shelley.u.washington.edu>
  7. Date: 7 Jan 93 03:05:33 GMT
  8. References: <1992Dec30.155939.13344@spectrum.xerox.com>
  9. Organization: Walker Richer & Quinn, Inc., Seattle, WA
  10. Lines: 18
  11. NNTP-Posting-Host: elmer.wrq.com
  12.  
  13. In article <1992Dec30.155939.13344@spectrum.xerox.com> weltman@adoc.xerox.com writes:
  14. >
  15. >  I followed the initial discussion in this group about RPC, TCP, and
  16. >UDP with great interest. At about the same time, a friend did a series
  17. >of benchmarks in a network of Sparcstation 2's, to compare the file
  18. >transfer performance using TCP sockets, NFS (write to remote-mounted
  19. >disk), and RPC using TCP. The files were large (around 2 MB or larger).
  20. >RPC using TCP was slightly slower than straight sockets using TCP, as
  21. >expected. What was surprising was that it was so slow to just do a
  22. >large write to the open file descriptor of a remote mounted file.
  23. >
  24. >Why is NFS so slow?
  25.  
  26. NFS is "stateless", which means that each "write" from the client side
  27. will result in an open/write/close on the server.  The opens/closes slow
  28. it down quite a bit over the file-transfers you were comparing it to.
  29.  
  30. -- Tad
  31.