How We Did It

By John Bass
Network World, 10/23/00

Our testbed is comprised of 10 clients with minimum configuration of two Pentium II processors running at 400MHz and 128M bytes of RAM. The largest client machine had four 400-MHz Pentium III processors with 1G byte of RAM. Each client has one 100M bit/sec Ethernet network interface card for connection to the Fast Ethernet test network.

We used Benchmark Factory to coordinate the test development, client load and result gathering and archiving for the Internet and the SQL tests.

The Internet tests made Active Server Pages calls to a Web server running Microsoft Internet Information Server 4.0 on the server. The test clients sent a request for a file of random size between 5K bytes and 15K bytes. The server then generated the file and sent it back to the client. The client then sent another request as soon as the previous request was finished. This is a worst case situation and is by no means a metric by which to judge how many real-world users the server can support. The traffic is real world, but the amount of load per user is not. Also, server I/O is kept to a minimum with this test. Each of the requests is read only.

The Internet test is repeated for increasing number of virtual users on each client. We went from one user to 15 users for our testing. This methodology was repeated for four, five, six, seven and eight processors. In all cases, the left processor bank was fully populated before populating the right processor bank. This entire process was executed for Windows NT Enterprise Edition with IIS 4.0 and Windows 2000 Advanced Server with IIS 5.0.

The SQL test uses Microsoft SQL Server 7.0. The methodology is very similar to the Internet test. For each processor configuration (four-way, five-way, six-way, seven-way and eight-way), the number of virtual users was increased from two to 30. The number of virtual users in no way implies a limitation of SQL server. Each virtual user in our test is atypical of a "real world" user in that the load generated by these virtual users is much larger than "real-world" users.

After spending a lot of time trying to develop the most computationally intense workload without completely killing the server, we decided on the following workload: Each virtual user calls the following Stored Procedure that resides on the SQL server; the virtual users then wait 9 seconds before executing the Stored Procedure again.

declare @value int

select @value=count(DB94float) from DB94_updates where DB94code like '%123%'

select DB94key, DB94code, DB94date, DB94signed, DB94name from DB94_updates where DB94key=@rand_input

end

This SQL statement is very computationally heavy thus reducing the number of network transactions per unit time to concentrate the load on the processors.

There were no special configurations made to either NT or 2000 for the test. TCP/IP sockets were used as the communication method between the clients and the server.