To conclude our study of push-caching, we compared push-caching to traditional client-caching. We simulated client-caching by assuming that once a client requests a given document that the same client will never again request that document. A side effect of this approach is that caches are assumed to be infinitely large, an unrealistic assumption because client caches are frequently small, but one which simplifies the simulation significantly because we do not have to worry about cache invalidation policies. Results for client-caching will therefore be somewhat optimistic. We used the values for server-initiated caching derived from previous sections, we set the caching-strategy to miles, and simulated setting the pull-strategy to miles, hops, and in the case of NCSA, random as well. The results are shown in Figures through .
Figure: A Comparison of client caching to push-caching on the NCSA trace. Note that hops-based push-caching and client-caching have equivalent performance, and that the combination of hops-based push-caching and client-caching is the most effective at reducing bandwidth.
Figure: A Comparison of client caching to push-caching on the FAS trace. Note that client-caching is extremely effective because FAS is a locally popular server. Most of its requests come from the same machines at Harvard including public, shared workstations.
Figure: A Comparison of client caching to push-caching on the DAS trace. Push-caching is particulary ineffective for this trace; Figure shows why. This server is the most diverse in that there is no small group of files accounting for the majority of requests, so there is no core group for push-caching to distribute.
Figure: A Comparison of client caching to push-caching on the HCS trace. The local popularity of this server accounts for the success of client-caching relative to push-caching.
Caching was most effective on the two most popular traces, NCSA and FAS, thus affirming the conclusion of section . Client caching and optimal push-caching used the same about of bandwidth, but they clearly were affecting different sets of objects because their combination proved most effective. Table displays more detailed statistics for the most popular trace, the NCSA trace. Notice that random pushing, while not as effective at reducing network traffic as hops pushing, was nevertheless more effective than using miles to push.
Table: Detailed examination of client-initiated caching versus server-initiated caching. The addition of server-initiated caching helps decrease network bandwidth consumption, but it also reduces the primary server load considerably. Note that we have included the primary server in the average server traffic calculation.
These simulations clearly show a need for all Web browsers to implement client caching, since the performance improvement is so dramatic, but they also show the advantages of push-caching in reducing the primary server load and network bandwidth consumption.