|
Nine Servers Stretched
Friday, August 10, 2007
This time, when we were arriving at the specs for doing the server shootout,
a large public sector organization approached us for help in deciding which
servers to purchase. This was the Centre for Railways Information Systems. There
could be nothing better than taking a spec from a real live usage scenario. So
instead of arriving at our own specs, we asked CRIS to provide us with one that
they were looking at. After multiple rounds of discussions, they arrived at
specs that are broadly mentioned in the side box on this page.
We sent this spec to all the vendors and requested them to participate with
appropriate models. We received 10 servers from all major vendors in the
country. Unfortunately, two of the vendors didn't adhere to the spec, and sent
us servers with two quad core processors instead of dual core. These were from
HCL and an Intel GID brand from Bangalore called SkyRunner. These were not
included in the rankings, but reviewed separately. One server from Dell arrived
late, and on top of that gave some technical problems. Therefore, we were not
able to include it this time. Hopefully, if we're able to resolve the problem,
we would be carrying it in our next issue.
The test setup
We realized from the specs that servers have become more powerful and we
would need a decent set of client configurations to be able to load them. Our
existing test setup, which had twenty machines with P4 2.4 GHz processors and
256 MB of RAM, was not capable of stressing these servers. So, we decided to
upgrade our setup. We replaced all the P4 machines with 1.8 GHz Dual Core
machines with 64-bit support and 512 MB of RAM. And, we used a Dual Xeon
processor based server, as the controller. All these machines were connected
over a Gigabit link. Before starting to benchmark the servers, we benchmarked
these clients and established that each of these clients is capable of
generating a load of around 170 Mbps. So that our total setup was able to yield
a stress-load of 3400 Mbps. That's sufficient to stress any Workgroup-class
server.
The benchmarks
Next, we had to decide which benchmarks to run on the servers. For this, we
once again considered the CRIS requirement. They were planning to run an
application that was more I/O intensive than compute intensive. Plus, the
maximum load they were planning to put on their server was 50 clients. We
therefore considered these specific requirements for arriving at our benchmarks
and for doing the calculations later to arrive at the results. There were four
key benchmarks that we ran on the servers. Three of these stressed the I/O
performance of the servers, while the fourth one stressed the compute power.
Here are their details:
NetBench
NetBench uses a number of client machines to generate file I/O requests to a
shared location on the server. It loads a server gradually. Starting with the
load generated by one client, it continues to add more load, as per the
predefined scheme, until it reaches the maximum load. You can also specify the
delay time, think time, the number of engines per client and many other such
things. As a result, it gives you the graphs of I/O throughputs and average
response time, at various load points. If you've loaded the server sufficiently,
then there will be one peak throughput point, beyond which the throughput will
start declining. For our tests in NetBench, we used 5 engines per client, so a
total of 100 engines, with all the clients running on WinXP with SP2. We used
CentOS 5 on the server being tested. One of the interesting points that came
out, while we were running NetBench on the servers was the number of clients for maximum throughput. Some servers gave maximum
throughout with lesser number of clients, while some gave the maximum throughput
with higher number of clients. The servers which gave maximum throughput with
larger number of clients have the potential to maintain a healthy performance,
even with sufficiently large number of clients.
To get the final overall score we took the maximum throughput at 50 clients
for all the servers. We selected this because this time we had a specific
requirement in our mind, and that was the application which CRIS was going to
use. Now to check for the available head room in all the servers over 50
clients, we also had taken into consideration the number of clients at which the
server attains peak throughput.
WebBench
WebBench is meant for testing a server's suitability as a Web server. It
provides the throughput of the server in bytes and requests-per-second answered
by the Web server. It requires Web server software to be running on the
server-hardware under test. You also need to copy the workload tree of WebBench
into the Web server directory of the server being tested. The workload tree
simulates usage of a website. It consists of various HTML and GIF files that act
as a website on the server being tested. WebBench provides both static and
dynamic test suites, which execute applications that actually run on the server.
Not only this, you can easily create your own test suites. Just like other
tests, we used WinXP with SP2 for the webBench clients and on the server we ran
CentOS 5 with Apache for the Web server. For deriving the final scores we did
exactly the same thing which we did with NetBench but the only difference was
that, instead of 50 we took 55 as the cut-off number of clients.
IOmeter
IOmeter stresses a device for I/O operations and its measurement tool records
the I/O performance of the device and their impact on the system. To do the
testing with IOmeter, we ran one instance of dynamo (IOmeter workload generator)
with one worker on every machine of the cluster. To stress the server, we tested
it with 64K transfer request size (the number of bytes read or written in each
I/O request) with 100 percent read and write, both randomly and sequentially,
for 2, 5 and 10 mins. From the exhaustive results, which IOmeter gave, we only
considered the 'Total I/Os per second'. It gave us the average number of I/O
operations per second, across the length of the complete test. Page(s) 1 2 3 4 5 6 7 8 9 10 11
|
