The next parameter we varied was the number of pages to push at a
time. The results are shown in Figures 
and
.
Figure: The effect of
pages-to-push on network traffic and primary host
traffic. Line-type denotes the pulling strategy in (a), strategies are
averaged together in (b). The server trace shown in these graphs is the
NCSA trace. Notice that the network traffic created by random pulling
increases as the number of pages pushed at a time increases.
Figure: The effect
of pages-to-push on average server traffic and active push-cache
servers. The server trace shown here is the NCSA trace. Notice that
the average server traffic and the active server number remain
essentially constant.
Our results did not match our intuition. As we increased the number of pages pushed at a time we noticed the expected initial decrease in bandwidth. However, for all but the random pulling strategy, the bandwidth consumption remained essentially flat as we continued to increase the number of pages pushed.
The linear increase in bandwidth for random server selection as the number of pages increases was the clue that helped us decipher these results. There are actually two effects that arise from increasing the number of pages: On one hand, increasing the number of pages increases the overhead of push-caching. On the other hand, increasing the number of pages improves push-caching's performance because more objects are available to clients from nearby servers. These two effects cancel each other out in the case of miles and hops server selection, but since there is effectively no push-caching in the case of the random server selection we see only the rise in bandwidth due to increased overhead costs, and none of the decrease due to more efficient caching.
The fact that the number of servers used remains essentially constant regardless of the number of pages pushed is not surprising, because the number of servers used is dependent on client access patterns, not the efficiency of the caching once the clients locate the servers.
So far this data indicates that pages-to-push should be set as
high as possible, because there are not any apparant sideeffects from
a high pages-to-push parameter. This is because we have not yet
considered the amount of cache space required at the push-cache
servers in order to store the replicated pages. We can compute the
efficiency of push-caching as bandwidth saved
cache space
required, as discussed in section ;
Figure displays this efficiency.
Figure: Effect of pages-to-push on push-cache efficiency. Note the use
of a logscale on the x-axis in enhance readability. As the number of
pages pushed increases, the efficiency decreases.
We see from this graph the cost of increasing the pages-to-push parameter: a declining efficiency. We suggest therefore that pages-to-push be set at 10. Performance is not improved significantly by setting it any higher, but the efficiency declines precipitously.