home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / protocol / nfs / 1949 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  4.0 KB
  1. Xref: sparky comp.protocols.nfs:1949 comp.sys.sun.hardware:3536
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!sun-barr!male.EBay.Sun.COM!exodus.Eng.Sun.COM!ennoyab.Eng.Sun.COM!beepy
  3. From: beepy@ennoyab.Eng.Sun.COM (Brian Pawlowski)
  4. Newsgroups: comp.protocols.nfs,comp.sys.sun.hardware
  5. Subject: Re: NFS I/O Ops/seconds
  6. Summary: nfs laddis nhfsstone
  7. Message-ID: <l7197tINN4eq@exodus.Eng.Sun.COM>
  8. Date: 25 Jul 92 00:49:01 GMT
  9. References: <1992Jul22.061146.15641@u.washington.edu> <12470@inews.intel.com>
  10. Followup-To: poster
  11. Organization: Sun Microsystems Inc., Mountain View, CA
  12. Lines: 80
  13. NNTP-Posting-Host: ennoyab
  14.  
  15. In article <12470@inews.intel.com>, mfineman@cadev5.intel.com ( Mark S. Fineman ) writes:
  16. > In article <l6r4uvINNf0p@exodus.Eng.Sun.COM> beepy@tabitha.Eng.Sun.COM (Brian Pawlowski) writes:
  17. > >...
  18. > >The number "300 NFS ops/s per ether" is a rule-of-thumb
  19. > >. . . 
  20. > 
  21. > From what I've heard from various people at various vendors of
  22. > file servers the PRE-LADDIS OP/S are about 2 times the
  23. > nhfsstone OP/S for equivalent mixes.
  24. > 
  25. >  150 or so would be fair for nhfsstone,
  26. >  300 or so would be fair for PRE-LADDIS.
  27. > 
  28. >  340 using PRE-LADDIS and the equivalent mix to the default
  29. >  mix in nhfsstone would be pretty good.  I don't think
  30. >  you could get 340 using nhfssone and that mix.
  31.  
  32. Enter slippery ground, and take following with "a your mileage
  33. may vary non-linearly" attitude:
  34.  
  35. 1. The 300 ops/s maximum is the rule-of-thumb maximum for PRE-LADDIS
  36.    and nhfsstone from Legato. 
  37.    
  38.    Of course, you will only see this if your server can handle
  39.    300 or more ops/s, *and* your "load generating" clients can
  40.    generate the load. And I have seen 325 ops/s on a single
  41.    ethernet for at least one (of the many) versions of PRE-LADDIS
  42.    I've evaluated.
  43.  
  44. 2. If you feel your server can handle more load than 300 ops/s,
  45.    you have two choices: (1) increase the number of low-bandwidth
  46.    pipes feeding your server (ethernets) or (2) go to a higher
  47.    bandwidth feed like FDDI.
  48.  
  49.    MTU characteristics and resulting NFS packet fragmentation
  50.    (reduce fragmentation) will account for slight differences
  51.    between a multi-ethernet server and one connected (directly)
  52.    with something like FDDI. There are a couple of reasons
  53.    for this, exercise left to the reader.
  54.  
  55.    [Remember PRE-LADDIS and nhfsstone measure the avg. response
  56.    time of the server at a given load. Both numbers--maximum
  57.    load and response time--are criticial to understanding server
  58.    performance. That's a hint to anser above question.]
  59.  
  60. 3. Not all network interfaces are created equal. The problems
  61.    people have had with PC ethernet hardware springs to mind.
  62.  
  63. 4. Another rule of thumb I use is that an SS2 or a DS5000 (which
  64.    I've a little experience with in NFS benchmarking) can generate
  65.    about 300 NFS Ops/s. In case any of you are doing this out
  66.    there.
  67.  
  68. 5. Legato's nhfsstone uses client NFS code to generate traffic and
  69.    PRE-LADDIS does direct RPC calls. Their load generation seemed
  70.    similar enough (when I did a comparison of pre-beta PRE-LADDIS
  71.    and Legato nhfsstone 1.21 or 1.22).
  72.  
  73.    nhfsstone *from* Legato depends on the client NFS code to
  74.    generate the NFS operations as a "side-effect" of file system
  75.    operations. In one sense, you can say nhfsstone 1.x is
  76.    "correct" since the load is actually generated by client NFS
  77.    code.
  78.  
  79.    PRE-LADDIS has abstracted load characteristics (such as read/write
  80.    request size) and performs the operations explicitly. In this case,
  81.    the benchmark is client independent--the same load profile
  82.    is presented to the server regardless of what client machine
  83.    is used.
  84.  
  85.    Anyway though, recognizing that they're different, I don't
  86.    believe there is a 2x difference in loading between the two.
  87.    Everything I've seen and experiments I've run point to a 
  88.    similarity of effect from the two load generating programs.
  89.  
  90. Take all this with a "I'll try it for myself at home" attitude.
  91. And remember benchmarking is an art. We should all take art
  92. lessons.
  93.  
  94. Brian Pawlowski
  95.