Testing Web application front-end devices
By Christine Burns, NetworkWorld.com, 05/06/05
Web application front-end devices (sometimes marketed solely as "application front-end" devices to conjure up more market appeal) are boxes that are used to offload core networking and I/O responsibilities from Web servers to increase performance.
Most Web front-end devices - like those offered by Array Networks, F5 Networks, Foundry Networks, NetScaler and Redline Networks - focus on speed, scale and security with a combination of technologies at multiple levels in the protocol stack. In our first round of feature-based testing conducted late last summer, we focused on basic features including TCP offload, caching and compression, as well as newer features such as URL rewriting and content balancing.
And, as promised, we are currently undertaking a second round of performance-based testing -- the first-ever public test of its kind - with Network World Lab Alliance partner David Newman of Network Test. Using a variety of Web content types, we will evaluate devices in terms of:
- Maximum concurrent client connections
- TCP multiplexing
- Maximum transaction rates
- Page response times
- URL response times
- Maximum forwarding rate
Newman has posted an outline of the full test methodology.
Many of the current Web application front-end devices have roots as server load balancers (SLBs). However, this methodology recognizes - and puts to the test -- the unique abilities Web application front-end devices, such as HTTP compression and TCP multiplexing. While it's not our goal to validate individual vendors' marketing claims, the methodology addresses scalability issues in several ways, including emulation of millions of clients and measurement of maximum forwarding rates across multiple gigabit Ethernet interfaces.
The test goes far beyond the simple drag-race approach of measuring throughput alone. Delay is actually a far more critical metric, since it answers the question of how quickly users get their pages. The Spirent Communications test tools we are using in this test measure latency in numerous ways. In addition to the Spirent tools, the testing sequence will also measure the benefits of web application front ends by using actual pages from heavily visited sites, including Amazon, the BBC, UCLA, the White House, and Yahoo.
What this methodology does not do is test all features of all Web application front end devices. For example, due to limitations of time and test equipment we will address caching in a sidebar but not test it in the lab. Nonetheless, the methodology does represent a first-ever effort to put performance numbers to the many performance claims offered by the vendors in this space.
We'll publish the test results in December. Stay tuned.
TrackBack
Back to Testing Notes
Comments
Post a comment
