Ever-increasing Internet activity and the demand for quicker, richer Web content has put serious strain on corporate and e-commerce Web servers alike. CacheFlow Inc.'s new Server Accelerator 725, which off-loads content-delivery tasks from Web servers, can significantly boost Web server performance - by eight-fold in our recent tests.
The SA 725 is a Web-caching appliance designed to sit in front of a Web server or server farm. It uses proprietary algorithms that eliminate the need to serially process setup and get requests for each object requested from a Web page.
The SA 725 runs on the company's proprietary, embedded operating system, CacheOS, and improves Web page response times by caching frequently requested content and off-loading Secure Sockets Layer processing from the Web server through a built-in SSL Accelerator. Off-loading SSL encryption from the Web server results in substantial increases in Web server performance.
Using CacheFlow's SA 725 on our test network, we reduced Web server CPU utilization from 90.6 percent to zero, increased transactions per second from 13.34 to 105.10 and decreased response times from 0.37085 seconds to 0.04654 seconds.
In addition to delivering significant performance boosts, the SA 725 was easy to install and offered excellent redundancy. However, incomplete documentation and a problem uploading server logs to an FTP server mar an otherwise straightforward management application.
Web pages comprise many different objects such as logos, script and text, which are retrieved serially when a user requests a certain page. For each object, a TCP session setup followed by an HTTP get request takes place between the user's browser and the Web server. Because there are multiple objects per page, there are multiple setup and get requests, which causes delays for end users.
The SA 725 eliminates delays through a proprietary algorithm called Pipeline, which lets many TCP connections occur simultaneously. These objects are sent directly from the SA 725 to end users as fast as a browser can request them.
CacheFlow uses another proprietary algorithm, the Adaptive Refresh Algorithm (ARA), to determine which objects on the Web page are most frequently requested. The ARA develops usage models based on how often an object is changed on the Web server and determines a refresh pattern for each object. The SA 725 automatically performs freshness checks with the Web server to ensure old content is replaced. The ARA determines which objects will take the most time to process and assigns items with longer response times a higher priority.
This combination of parallel processing of setup and get requests, object refreshment and priority assignment, as well as the off-loading of SSL processing, combine to produce a substantial performance boost.
The SA 725 survived a jolt2 denial-of-service attack, which we ran in an attempt to "break the box." We stressed the SA 725 by sending enough SSL connections to bring CPU utilization up to 100 percent, then began the attack. During the attack, the SA 725 continued processing SSL connections, albeit at a lower rate.
The SA 725 offers excellent hardware redundancy. Redundant hard drives each support the CacheOS and can be configured to fail over from one device to another.
The SA 725 installation was one of the easiest we've encountered. Initial IP address assignment is through a joystick. Once that is done, four prompts appear on the screen. After values are entered for each item, the SA 725 is operational.
For security reasons, configuration of the SA 725 is done only through the serial port on the console because we had to install keys to facilitate SSL encryption.
But this, too, was a straightforward process. We copied and pasted the key codes, which were available as flat ASCII text files on a disk, into the console, and we had SSL processing up and running.
The SA 725 is managed via a Java application that runs inside a Web browser. The management screen is well designed and includes a navigation bar on the left side of the screen that we found intuitive and easy to use. SNMP is supported to monitor events through public Management Information Bases.
While we found the management application good overall, scoring in this area was negatively affected by the lack of a glossary in the documentation.
Noteworthy was the SA 725's ability to create its own server logs that provide precise data about client use of the Web site, which can be passed on to the Web server.
A Web server also provides this information, so data from both devices can be compared and combined for a precise look at visitor behavior. CacheFlow simplifies this procedure by uploading the log files from the SA 725 to an FTP server so files can be viewed offline. However, we could not get this feature to work due to a bug in the software.
The SA 725 proved it significantly boosts Web server performance by off-loading SSL processing and reducing the latency inherent Web page retrieval. The product is easy to install, easily managed and offers excellent redundancy.
Yocom is senior editor, Bilger is senior lab test engineer and Brown is lab test engineer at Miercom, an independent testing lab in Princeton Junction, N.J. They can be reached at firstname.lastname@example.org, ubilger @mier.com and email@example.com.
How we did it
We conducted testing using the Apache 1.3.12 open-source Web server (available from the Apache Software Foundation, www. apache.org).
The Mercury Interactive LoadRunner test tool (www.merc-int.com), Version 6.5, simulated HTTP connections, get requests and Secure Sockets Layer (SSL) user connections to the Web server. It received statistics regarding response time, the number of connections in use and measurements of CPU and memory usage on the server. The LoadRunner ran test scripts that were configured to download Web pages from the Web server and the SA 725. We ran a jolt2 denial-of-service attack from a Dell laptop running Linux Red Hat 6.2.
We ran two sets of tests to determine Web server CPU utilization, transactions per second and transaction-response times. In the first set of tests, five "users" requested one object via SSL directly against the Apache Web server. In this test, the LoadRunner showed that Web server CPU utilization was 90.6 percent, and we observed 13.35 transactions per second and a 0.37085-second transaction-response time.
Next, we ran the same test against the SA 725. Results showed that CPU utilization on the Apache Web server was 0% (because objects are stored in the SA 725 cache and SSL processing is handled there instead of the Apache server).
We observed 105.10 hits per second - an eight-fold increase over the previous test - and a 0.04654-second transaction-response time, reflecting about an eight-fold decrease over the previous test.