Uncork the performance of caching appliances - Technology Tutorial - Tutorial

Communications News, May, 2001 by Edward Sharp

Analysis of bottlenecks may be cause for celebration.

Two basic approaches are used to test the streaming performance of caching appliances: in a live environment or in a lab. The benefit of live testing is that the system is performing in the real world of network traffic with a variety of users, hit rates, downloads and transport protocols. The drawbacks are that you must put a live environment at risk, and you do not measure the performance of the box alone.

Lab testing, on the other hand, offers total control of the test and all its parameters, resulting in a true performance test of the box--but not a test that represents what the box will do in the real world.

Three bottlenecks have held down Internet streaming performance:

* long-haul networks between streaming servers and POPs, where bandwidth is shared randomly by many users;

* streaming servers, which are often overloaded during peak demand; and

* local loop connections, such as 56 kbps dial-up modems, which may require a 3,500:1 reduction from original video content.

Improvements are being made to solve the bottleneck issue: networks are increasing bandwidth and deploying edge caches; local loops are building out broadband connections and using improved codecs; and streaming servers and caches are increasing in efficiency and output bandwidth, supporting more end-users simultaneously. They are now being installed at the edge of the network, scaling both bandwidth and infrastructure, to copy streaming file content and deliver it to local loops. Network managers, however, need to measure or estimate the performance of streaming servers and caches before they can deploy them effectively.

REVIEWING TEST PARAMETERS

One of the primary goals in performance testing is to measure throughput under a variety of conditions. The first task, then, is to estimate the typical load on the cache or server. Begin by estimating the number of users at typical and peak load periods, bearing in mind that all the following variables affect equipment performance and should be included in the test:

* streaming format;

* simultaneous support for more than one streaming format;

* simultaneous support for HTTP traffic;

* hit rate (percentage of hits that draw content from the cache);

* quality or bit rate of the stream per end-user, transport protocol (examples: TCP, UDP, HTTP-encapsulated);

* dynamic adaptation of streaming quality (monitoring and altering bit rates to demand);

* processing time and bandwidth required to retrieve files, live/ broadcast vs. on-demand serving; and

* usage patterns.

These characteristics are often determined by planned usage. In corporate environments, streaming needs may consist of on-demand training and internal live events, as well as critical Internet news feeds. Cost constraints in branch offices often mean that servers must simultaneously deliver streaming and HTTP Web content--yet the two kinds of traffic are typically tested separately in the lab.

To save costs and simplify management, the organization may choose a single streaming format to deliver all content. Note also that many employees may be requesting streams originating outside their corporate firewall, such as Internet radio, which often requires the streaming server to switch over to HTTP-encapsulated--or "cloaked"--streams.

These Internet radio streams may be served at 20 kbps (primarily audio), whereas on-demand training may be operated at 256 kbps per stream to assure acceptable video quality. What this all adds up to is that testing of caches for branch offices should include simultaneous HTTP and streaming traffic, with TCP, UDP and HTTP-encapsulated transport, for broadcast and on-demand traffic, at different bit rates.

In Internet content delivery networks that provide large-scale service, there may be enough traffic to justify separate edge servers--some dedicated to HTTP traffic and others to the major streaming formats. If content is pushed out to the edge servers before users request it, most of the streaming server's capacity can be dedicated to output.

If the pull model is used to fill the edge server content cache, the lower hit rate (the percentage of times the requested content is already in the cache) will impact output performance. If the hit rate is below 100%, the server must simultaneously copy requested content into the cache and serve content to users.

CHOOSING A TEST ENVIRONMENT

The next question is, "Will you test in a live environment or in a lab?"

Live environment. If you have a user population that is large enough and is willing to participate, live tests can deliver throughput measurement that includes all the above parameters. The upside is that performance measurement is representative of actual operating conditions.

Testing in a production environment puts the server under real-life loads, and finding user groups large enough to test the server to its limits may be easy. The downside is you cannot control test conditions; you put your network at risk; and you cannot isolate the box's performance. Although you cannot control test parameters, you should monitor and report them to relate test results to the real world.