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.