Early products handle traffic well, but need some polish

New Web front-end devices from Array Networks, NetScaler and Redline Networks each offer valuable techniques for dealing with growing traffic and security concerns. But while they can help improve site performance, we found plenty of rough edges.

New Web front-end devices from Array Networks, NetScaler and Redline Networks each offer valuable techniques for dealing with growing traffic and security concerns. But while they can help improve site performance, we found plenty of rough edges.

In this round of testing, we focused on basic features including TCP offload, caching and compression, as well as newer features such as URL rewriting and content balancing. We plan to test these boxes again later this year for pure performance.

Web acceleration options on the cheap

How we did it

Archive of Network World reviews

Subscribe to the Product Review newsletter

Our Clear Choice award goes to the Redline E|X 3250, which excelled in our compression and TCP offload tests, and addressed important compatibility details. Additionally, Redline's powerful - albeit complex - OverDrive technology allows for highly customizable rewriting of inbound and outbound data, which can be used to improve security, make sites more adaptable to changes, and even improve performance with cache control.

The Array TM offers strong caching at a decent price and provides a layered approach to its other features that lets you add them as needed.

The NetScaler 9950 Application Switch is very focused on the needs of extremely high traffic sites with features like surge protection and priority queuing. However, it lacks any significant amount of URL rewriting features and had some issues with compression.

Redline: Strong Web delivery features

The Redline E|X was built for Web acceleration and is concentrated on realistic details - such as browser compatibility - that might be encountered with a public-facing Web site.

Installation and initial configuration is similar to that of the other devices tested: You set up basic network configuration via a serial connection and then perform further configuration via a Web interface or a Secure Shell connection.

While Redline provides a clean Web interface that offers some nice monitoring statistics, many features cannot be addressed via the Web interface. It covers basic network and cluster configuration, but ultimately you have to access the command line to tap into the more advanced features such as setting compression details or enabling caching features.

From the load-balancing perspective, Redline's default load-balancing method is that new requests go to the back-end server with the fewest outstanding HTTP requests. The company argues that looking at lower-level TCP-based metrics for load balancing is not effective. Redline engineers point out that by focusing on HTTP requests, literally every request made is considered a health check for the Web server. Our take is that while Layer 7-oriented load balancing and health checks might seem unfamiliar to some network administrators, they make perfect sense at least for Web-based applications.

Like the other products tested, the Redline unit offers TCP connection buffering and management as well as SSL  offload and acceleration. However, one area in which the Redline unit really shines is in HTTP compression. The Redline E|X was very aware of edge case issues with browser support for compression, and even opted to use deflate over standard Gzip compression for improved compatibility with browsers, given that some browsers have bugs that only occur with Gzipped content.

Redline provides more control over the degree of compression you can use than the other devices tested, even if you have to use command-line interface in this case.

In our compression tests (See How we did it ), we obtained the lowest overall delivery size (46,273 bytes for a 36.64% savings) of the units tested using a real-world example of the BBC's home page (original size 73,031 bytes). With some tuning, the device also aced our pre-built tests that addressed various mixtures of HTML, Cascading Style Sheets (CSS), JavaScript and images.

One compression annoyance is that the Redline unit inserts a somewhat excessive "advertising" header (so if you do a network trace you see a "powered by Redline'' tag) in every response, which skewed its results in the unit tests until we turned off the headers.

Redline OverDrive's AppRule language lets an administrator write powerful rules to filter and rewrite HTTP requests and responses. For example, a rule can be added to redirect requests for particular file types to a certain server, clean URL requests to make them user-friendly, and drop requests that contain certain known worm or attack signatures. The language is so flexible it can be used to add or remove headers at will, and even rewrite textual content in the body of responses on the fly. We were very impressed with this feature when we applied a rule to change the name of one company to another in a set of test HTML files.

OverDrive was frustrating at times. The language is terse and not always intuitive. Furthermore, it can be quite a chore to add AppRules by sending a file via trivial FTP to the unit or copy and pasting them into a file and then using command line to parse them. Redline should add rule support to the Web interface and provide a client-side tool to assist in creating valid rule files.

Redline's new "3G" caching feature lets developers create a cache on the unit and write AppRules to hold content in the cache depending on file extension, response code or whatever metric seems appropriate. Once the object is cached, future requests for it will be serviced by the Redline box, thereby freeing the origin server from the request.

Redline's approach to caching is not the automatic cache mechanism that the other two tested products provide. You must define rules to add files to the cache and understand when to invalidate them manually. This power can be dangerous if you aren't aware of application and browser cache policies. For example, we found that the unit happily sent the Firefox browser content even though the browser sent cache control headers indicating it wanted fresh copies.

The Redline E|X is clearly designed from the HTTP layer downwards. The product excels in HTTP compression, application-level redirection and balancing, and request and response rewriting. The 3G caching feature does not live up to its fancy name (implying it's seasoned code), although it can be useful if properly employed.

Array: Strong caching, room to grow

The Array TM is an example of a device that is good at many things, but does not excel in any one area. However, Array's delivery approach to front-end devices lets you buy a base unit with typical load-balance features and then add on other features as you need them. This contrasts greatly to NetScaler, which provides many features by default that go unused by many site owners.

The Array TM's Web-based interface is generally clean and relatively intuitive but it's not without its quirks. A confusing GUI made it bothersome to determine if configuration changes took hold. We also had trouble with monitoring graphs for our unit even after an Array engineer investigated the problem.

The help system, while context sensitive, was not nearly as helpful as we would have liked and often lacked examples of command usage. However, some administrators might find that the Array command line uses syntax that is similar to Cisco's IOS .

The core load-balancing features of the box contain familiar algorithms like round-robin and least connections. However, load balancing also can be based on URL request type. Even better, you can determine where to route a request based on arbitrary HTTP request headers values. TCP offload features are part of the equation helping to offload the back-end servers.

The Array TM can perform basic URL rewriting such as changing file extensions from .asp to .htm or cleaning a query string from ?id=test to /id/test. Basic content filtering can be performed to block requests based on signatures you define. The Array documentation obtusely suggests the box supports response rewriting, but we couldn't get this to work. However, some basic response needs such as dumping server headers can be done from within the GUI.

The Array's reverse-proxy cache feature called SpeedCache is well done and offers an ample cache size that ranges from 512M to 2G bytes depending on the device configuration. Caching is mostly automatic and invalidates changed content properly. The device also provides features to force objects in cache manually, as well as support for byte-ranges in cache, which would be useful for big files or PDF files in particular. We were happy to find the ability to inspect items in cache and flush them easily because that can be useful when debugging.

During our test of the caching feature on the Array box, we ran into an interesting problem with Mozilla-based browsers like Firefox. Because these browsers send a cache-control header in request indicating a maximum age value of zero, they effectively bypass any caching provided by the front-end proxy. Neither Microsoft's Internet Explorer nor other emerging browsers such as Apple's Safari or Opera Software's Web browser, do this; therefore it's not an issue when using those browsers.

The Array device supports standard HTTP compression using Gzip. The implementation is middle-of-the-road. It provided some rules to address browser compatibility and addressed other file formats for Microsoft Word or PDF by default. Unfortunately it provided minimal tuning of compression rates, and it came in last place for overall compression savings on a number of our unit tests. However, in the case of the real-world test using the BBC home page, it finished second with 48,382 bytes representing a 33.75% savings.

Overall, if caching is one of the main features you want besides load balancing and connection management, the Array TM warrants a closer look.

NetScaler: Built for traffic

The NetScaler 9950 Secure Application Switch has roots in the traditional load-balancer camp, but it has been optimized with a variety of interesting features, including surge protection, that are geared toward extreme traffic situations. NetScaler says its rates as high as five million requests per second. Our subsequent performance test will investigate these claims, as it would put NetScaler on a short list for sites with monster traffic. Taking raw performance out of the picture, though, many times during feature evaluation we wished NetScaler had spent more time ironing out important features details before moving on to pure speed.

Installation is fairly easy. Administration of the device is performed via a Web browser, which accesses a Java applet-based system. Most everything, including setting policies for determining what to do with requests, can be performed via the Web interface, albeit clumsily at times.

The NetScaler box also supports a command-line interface. However, this one oddly encourages administrators to tap directly into the core BSD operating system  beneath.This is discouraging from a security perspective. Instead of finding a stripped down, hardened operating system, we found a full complement of development and network tools that would let an intruder set up shop easily.

The NetScaler 9950 also handles TCP connection management and buffering. While the load-balancing policies seem more in-line with traditional load balancers with metrics such as least connections, least traffic and least bandwidth, it also can perform basic content switching. For example, you can balance URL requests for images to a particular server, SSL requests to a certain server, or even balance by protocol. NetScaler also provides the ability to filter requests based on certain signatures in the headers, request or content. By default the device contained some basic filters for common worm signatures, but it is up to the administrator to determine what should be filtered and what should be allowed.

While the NetScaler product does have a fairly rich policy language that can be modified via a GUI, it's not a full rewriting language like Redline's OverDrive technology. The language only lets you direct or deny requests. The device can't rewrite requests and can't touch responses, including something as simple as removing the server header of the origin server.

One of the unique features NetScaler provides is the ability to prioritize requests so that you might service high-priority requests and deny or redirect suspicious traffic. This priority queuing feature also acts as HTTP distributed denial of service protection by using JavaScript, redirects and cookies to help sniff out faked HTTP GET requests coming from clients that will never respond. Another interesting surge-handling feature is the ability to build an effective "please stand-by" page that goes back to end users and asks them to retry later when dealing with extremely busy servers or overloaded back ends. This feature might be useful to e-commerce sites facing extreme load for a short time period.

HTTP compression is not a strong suit for NetScaler. By default the device does not compress JavaScript or CSS, although NetScaler does provide a workaround. Proceed with caution because the device doesn't have rules built-in to address various browser-compatibility problems.