Array of Light: Page 2 of 3

Although I experienced no problems during testing, the proprietary OS has a unique approach to preventing DoS (denial of service) attacks in its TCP/IP handshaking process that can reject valid connections.

Does It Perform?

I inserted a single Array TM device configured for caching into our network and configured a virtual service served by a Caw Networks' WebReflector. The Web-Reflector was set up to provide three virtual Web servers, each serving up a 1-KB file. Load generation was provided by Caw's WebAvalanche, with each virtual user performing a single transaction consisting of 15 requests. This was designed to simulate a single page request comprised of 15 different 1-KB Web objects. I turned on the Array TM's caching feature and barraged it with requests.

We reached the limits of the Avalanche when it reached just over 27,000 HTTP 1.1 gets/second. While the Avalanche test was running, I conducted additional tests with Microsoft's Web Application Stress Tool (WAST) and ApacheBench. The Array successfully performed an additional 1,500 gets/second while maxing the capabilities of the two additional client machines. Dropping the number of Web objects in a transaction from 15 1-KB objects to one 14-KB object caused performance to decrease to 8,000 gets/second and reduced CPU utilization on the device from 80 percent to 30 percent. Turning the cache off resulted in 6,000 gets/second to retrieve a single 14-KB file.

I enabled the compression feature on the same 14-KB file and was delighted by the result. Rather than transferring 14 KB per request, the device transferred a mere 106 bytes, dramatically reducing the amount of traffic on the wire. Your results will vary, of course, depending on the content being served. The Array TM uses RFC standard gzip compression based on the client's ability to accept such content.