In the first experiment, an increasing number of clients
continuously made CGI requests to
either of two Web sites hosted at node S.
Processing of each of these CGI requests consists of computing
half a million random numbers (using rand()) and
returning a 1 KB reply. Therefore, the bottleneck resource is the
CPU. We measured the average throughput and response time
(over three minutes) under the following scenarios:
(1) The site of interest reserves 50% of the CPU and the
competing site reserves 49% of the CPU;
(2) The site of interest reserves 99% of the CPU; and
(3) Both sites run in the same CPU reservation and reserve 99% of the CPU.
Figure 4 shows the throughput of the site of interest when
the latter has ten clients and the competing site has a
varying number of clients, and Figure 5 shows the
corresponding response times. Performance when both sites run in the
same CPU reservation on Eclipse/BSD is roughly the same as
performance on FreeBSD.
When the site of interest reserves
99% of the CPU, its performance is essentially
unaffected by other load. When the site of interest reserves 50% of
the CPU, it still gets essentially all of the CPU if there is no other load,
but, as would be expected, the throughput goes down by half and the
response time doubles when there is other load. However, throughput and
response time of the site of interest remain constant when further load is
added, while on FreeBSD throughput decreases and response time increases
without bound. This shows that FreeBSD and Eclipse/BSD
are equally good if there
is excess CPU capacity, but Eclipse/BSD can also guarantee a certain minimum
CPU allocation (and consequently
minimum throughput and maximum response time).
 |
