Here's my summary of the responses for my request for information on
determining an appropriate server/client ratio.
As I suspected there is no easy answer.
The only rule of thumb I could glean from the replies is this:
10-20 clients per server for diskless clients.
up to 40 clients per server for 'diskfull/dataless' clients:
Although, if all clients have disks providing /, /usr and
swap space then the network is simply a luxury for user storage
and interconnectivity that isn't used for any standard client
service anyway so I could expect to see more than 40 clients
work nearly as well.
An interesting point was that SPARCstation1's (& family) are reported to
severly beat on the server and could be a bottleneck (expecially less capable
servers).
As stated in the original posting (reprinted below) we run 20 clients (22 now)
diskless from a single Sun4/390 with somewhat sluggish behavior. The
sluggishness is not objectionable yet, despite a "considered opinion" that
we were most unwise trying to run diskless sun4's.
We run diskless by design. We could buy tiny-disks to provide swap space
for very heavily used clients if this is indeed a bottleneck.
All our machines have adequate memory. Many clients have 24M. All
SPARCstations have 16M, All clients have at least 8M.
We've never had any any ethernet load problems that were not traced to
malfunctioning equipment or improperly configured software creating packet
storms.
Our users are relatively sophisticated and use sunview and XNeWS
(50/50) almost exclusively. We use the machines individually as well as in
concert to produce professional papers and books that are the result of our
research into Neural Network processing of SONAR and speech pattern
recognition, VLSI design of neural network chips, simulation of neural network
algorithms, as well as extensive mathematical analysis of optical, radio &
audio, signal processing techniques. We do not use these machines as "toys"
(not even the 3/50's) and our diskless SPARCstations1's (4/60) are taken very
seriously and are not "just for ha-ha's".
Both sun4c architecture servers provide service for 6 SPARCstations. The
9-client Sun 4/280 is working as well as the 20 client 4/390.
Diskless machines have worked out well for us, I hope this information is
helpful.
There was an offer of a couple of measurement packages.
There was a short discussion of measurement terminology.
The excerpted replies are listed below:
The many requests for summary are hopefully covered by this posting.
############################################################################
ORIGINAL REQUEST:
Any information about determining an appropriate server/client ratio?
Assuming Sun s/w on Sun h/w only and infinite disk storage space for swap
files then:
How many clients per server?
How many packets per second?
How many NFS whatsits per second?
How SLOW can you GO, before user frustration sets in.?
I know this is probably an unanswerable question but I'm interested in
hearing rule-of-thumb answers. (Any real science would be appreciated!)
I'm currently running the following situation in our department:
Department private Class C subnet on Corporate Class B network
Sun 4/390 32Mb w/20 clients (sun3 sun4 sun4c)
Sun 4/280 40Mb w/9 clients (sun4 sun4c)
Sun 4/390 32Mb w/1 client (sun4) + heavy VLSI design
Sun 3/180 16Mb w/2 clients (sun3) + print, manuals, & serial I/O service
My opinion is that the Sun 4/390 w/20 clients is beginning to give sluggish
service. I've been tasked with proving that it is due to client load.
How and what do I measure?
Who do I believe (Sun? Users? Myself?)
Why is there air?
Daryl Crandall
The MITRE Corporation
mail stop: Z-425
7525 Colshire Dr.
McLean, VA 22102
USA
(703) 883-7278
daryl@mitre.org
############################################################################
REPLIES
############################################################################
We've been doing some server benchmarking so I thought I might be able
to give you some our current feelings.
Auspex has benchmarks that use a cutoff point of 70ms response to any
given packet as the longest reasonable wait by a client. We haven't
played with this number, but it seems reasonable. The problem is that
there is no way to measure the response time through normal software.
You can look at the packets per second (via nfsstat) and that is one
useful measure, but only nhfsstone (from Legato, an artificial NFS load
generator) will measure the response time, and only when it is being
run for benchmarking.
You might want to get a copy of nhfsstone and tun test on all your
servers to determine their _relative_ speed, but of course benchmarks
never tell the whole story.
I take it from your question that you have all diskless
workstations...this is a big lose in our opinion and we only run
disked systems. In that configuration we have 180 workstations served
by 4 4/280 servers (home directories, large projects, and some
binaries are on the servers...most of the OS, paging, and the kernel
is on the local disks). We're finding that the servers are running
out of steam, so we're replacing them. At their peak, and when
performance seems to be suffering, we've seen nfsstat return _45_
NFSops per second from each server. That means we get an average of 1
NFSop being satisfied per workstation when we are busy. I think the
number being requested is a little higher than this. I'd also
guestimate that 5 NFSops per second is more of the norm for diskless
workstations. So, your 4/280 with 9 clients is giving you reasonable
performance (9*5-45 requests). You now need to find out how many
NFSops the 4/390 can put out. It sounds like it is less than 20*5=100
NFSops. The way to tell would be to use NHFSSTONE on the 4/280,
figure out the percentage difference between the result and the real
number you get (via nfsstat over busy periods), and then do the same
test on the 4/390.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:58 CDT