How Ee Tested...
Web Servers
To test our Web servers, we used several pieces of hardware. Each client load generator was an Intel Pentium 200 MMX PC configured with Microsoft Windows NT Workstation (Service Pack 5) and 64 MB of RAM. Our three Compaq ProLiant servers (1850R, 3000 and 6000) contained four 500-MHz Pentium III processors with 512 KB cache per processor and 512 MB of RAM, and our prerelease Sun SPARC server had four 500-MHz SPARC CPUs and 4 GB of RAM. All servers featured Ultra SCSI-2 hard drives. A Lucent Cajun P550 FE switch connected servers and clients. We also ran Netscape (a.k.a. iPlanet) Enterprise Server and Apache Server tests on a 300-MHz Sun Ultra 10 with 256 MB of RAM.
Before we ran our test suite, we performed tests to calibrate the load agendas and generator configurations with our client load generators. On one Intel machine, we measured bandwidth and request rates for various loads using RadView's WebLoad software. This program's Cruise Control feature adds clients at a gradual, specified interval until a goal is reached. We set the goal to be the maximum number of clients we could use effectively.
We used the Static 1-Kbps to 20-Kbps HTML agenda and the quad Sun and Intel machines to put the greatest load on the clients and server machines, with the least network traffic. Then we configured WebLoad to start with one client machine and a load of two, adding a client and load every 30 seconds. When the client load reached 76 (38 machines), the perfect stair-step relationship between clients and network bandwidth broke down and leveled out at around 11.8 MBps (94.4 Mbps) HTTP payload, an acceptable limit.
The smallest page tests produced the most client requests, and thus taxed the servers the most. SSI (Server-Side Include) tests taxed the CPU even more heavily. Data was never bigger than 20 MB. With such huge RAM configurations, 99.9 percent of our client requests came from the servers' cache; thus, we could remove the hard drive from the performance evaluation.
We also used persistent connections for all tests, so that each TCP session would remain open throughout the test. This configuration resulted in the best performance numbers. Had we used nonpersistent connections, performance would have decreased and we would have had to perform some TCP tweaks.
Our scripting tests performed a case-sensitive search through a 200-KB text file (/usr/dict/words) that returned all matches. These applications are easy to code across all languages. Perl and Perl-based scripting mechanisms have an advantage over such alternatives as ASP in this application. Our tests provide points of comparison using a common scripting method across all platforms in a common application, demonstrating each language's text-parsing ability.
|
REPORTS
ANALYTICS
Follow 
