## 4 Performance Evaluation and Comparative Analysis
### PF-ClusterCache Performance Analysis  
Different parameters directly impact the performance of PF-ClusterCache and any other caching scheme. We concentrate here on the performance of PF-ClusterCache and we present a comparative analysis with other caching schemes in the next section. To ascertain the quality and efficiency of PF-ClusterCache, we only consider popular traffic but using different numbers of content groups to generate different traffic flows. Mixing popular and unpopular traffic flows will be considered in the next section in the comparative analysis. We shall vary the number of flows from 1 to 40 popular flows. We shall also consider different parameter values for the popularity parameter of the Zipf distribution function to manipulate different popularity levels. The size of the Content Store plays an important role and shall be varied to investigate its impact. We shall also investigate different freshness values. Recall that we fixed the PF-ClusterCache popularity threshold to 2 and the EWMA period, for smoothing the popularity counts, to the same value as that of the freshness period. The traffic intensity submitted to the network depends on the number of consumers, the number of flows, and the simulation time. Recall from Table 1 that we are considering 30 consumers and a traffic rate per flow per consumer \(\lambda_{g}=2.5\) Interests per second, which amounts to a large number of generated Interests equal to 750,000. We performed ten different simulation replications for each considered scenario. The obtained 95% confidence intervals are very small and we chose not to sketch them on the different curves for better clarity of the figures. Figure 5 illustrates the server hit reduction (SHR) as a function of the CS size and for different numbers of popular traffic flows. Here, we used a Zipf parameter equal to 1.6 and a freshness period equal to 50 s. A remarkable server hit reduction above 90% is obtained when using only one traffic flow. The SHR decreases with the increase in the number of traffic flows and this decrease becomes smaller as the the CS size becomes larger. Recall that PF-ClusterCache regards the caches of the different nodes of the local cluster as a unique distributed pool of storage. This pool of caches is shared among the different traffic flows generated by consumers connected to the nodes of this cluster. Moreover, the underlying LPF replacement policy enforces that only the most popular data content of these various traffic flows can persist within the pool for the duration of its freshness. At the extreme, when there is only one popular traffic flow, the most popular data content of this flow obtains the entire pool, which is large enough to host it without any LPF eviction. As we can observe from Figure 5, even a CS size equal to 5, which is a pool of 50 places, is enough to attain the maximum SHR value. More traffic flows require a larger pool and a larger CS size. For a number of flows equal to 10, we need a CS size larger than, say, 20 to approach the highest SHR value. Freshness also plays a role as any cached content becomes stale when its validity expires, and if requested, must be retrieved from its producer. Therefore, PF-ClusterCache provides a different maximum SHR for different numbers of flows; the smaller the number of streams (or flows), the higher the maximum attainable SHR. Figure 6 depicts the SHR as a function of the Zipf popularity parameter and for various numbers of popular traffic flows. Here, also the freshness of data content is fixed to 50 s. We observe the great efficiency of PF-ClusterCache as the content popularity becomes larger. An increase in the Zipf popularity parameter provides higher frequencies for the most popular content, which restrains the range of this most popular content, and consequently less caching storage is required. In this figure, the CS size is fixed to 10, which is adequate for few traffic streams.