How We Did It

How We Did It

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

The eight-way server we used for testing was a Dell PowerEdge 8450 model with eight, 550-MHz Pentium III Xeon processors with 512K bytes of Layer 2 cache and 2G bytes of RAM. The server was connected to a PowerVault RAID array enclosure that housed eight hot swappable 9.1G byte 10K rpm Ultra2 SCSI hard drives. The server had room for two hard drives, and we used one drive for Windows NT and the other for Windows 2000.

We used Quest Software's Benchmark Factory to coordinate the test development, client load and result gathering and archiving for the Internet and the SQL Server 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 would then generate the file and send it back to the client. The client would then send another request as soon as the previous request was finished. This is a worst case situation, and not a metric to judge how many users the server can support. The traffic is real world, but the amount of load per user is not because the point of the test is to saturate the CPUs, not to measure how many users the server can support. Also, server I/O is kept to a minimum with this test. Each of the requests is read only.

The Internet test was repeated for increasing number of virtual users on each client. We went from one user to 15, repeating it 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 both Windows NT 4.0 Enterprise Edition with IIS 4.0 and Windows 2000 Advanced Server with IIS 5.0.

The SQL Server test used Microsoft SQL Server 7.0 with methodology that was very similar to the Internet test. For each processor configuration (four-, five-, six-, seven- and eight-way), the number of virtual users was increased from two to 30. The number of virtual users does not imply a limitation of the 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 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 and then the virtual users wait nine 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 computationally heavy, 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.