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 savedcache 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.