In November 1999, we compared two CacheFlow products: one CF-5000 and a group of five CF-5000s. The caches have been tested in our lab with DataComm-1 workload. We followed the DataComm rules, methods, and presentation formats to make it easier to compare results.
DataComm tests were first launched in June 1999 for Data Communications magazine. A detailed description of the DataComm-1 workload and June testing is available elsewhere. As many of our readers know, CacheFlow participated in June testing with a CF-5000 two-headed cluster. Since June, CacheFlow has reconfigured the CF-5000 and improved the CF-5000’s performance on DataComm-1 workloads. We mark the June results as “CF-June” in this presentation for ease of comparison. In the Box Configurations section you will find important configuration details of the tested products.
As always, we do not provide buying advice. We provide performance metrics and expect the reader to use this information, along with other important factors, when making decisions.
1. Summary
The “Summary” table below shows the performance results. Complete polygraph journals are also available for those who wish to reproduce results not listed here or to extract measurements.
Global box
price
($) Author
lay down
(request / sec) Average response
Time (sec.) Hits
relations
(%) Price / Perf.
(request / sec / $) Permanent
connections
Hit all Miss Clt SRV
CF-June
two Beta-CF-5000 191990 2000 0.27 2.05 3.90 50.91 10.4 yes no
Unit rev
one CF-5000 179990 2300 0.08 1.49 3.21 54.98 12.7 yes yes
Cluster
five CF-5000 805 985 13000 0.08 1.51 3.21 54.67 16.1 yes yes
The Total Price column is the sum of the list prices of caches and network equipment in the test configuration. In our price / performance analysis, we use the total price, not just the cost of the cache, to tune the expensive hardware that might be required to achieve high performance and / or to group individual caches into clusters. If the player already has the necessary network components, the price / performance ratio must be adjusted.
Average response times are shown separately for calls and failures to show proxy savings and overhead on the two most important request paths. The All column displays the response times for all requirement classes.