# Content Management Based on Content Popularity Ranking in Information-Centric Networks
## 4 Performance Analysis
### Cache Hit Ratio  
After measuring the AHC, we considered Cache Hit Ratio (CHR) as another key performance indicator. CHR is the ratio of how much of the requested content was readily available at a server node versus the total number of content requests, whether it was readily available or not, and whether it had to be fetched from the other servers. The existing content at the local storage of the server nodes needs to be replaced over time with new content as more and more content are being generated, requested, and cached. Therefore, cache misses may naturally occur due to the unavailability of the requested content at a particular server node. If the cache size of the server nodes is fixed and the number of available and requested content in a topology increases, the existing content at the local storage of a server node needs to be removed and replaced with the new content more frequently. Therefore, more cache overflows will occur, and more cache misses will follow. The Cache Hit Ratio can be increased, and the cache misses can be reduced by strategically removing the less popular content based on its CPR, as done by the proposed CPR-based cache removal scheme. A higher CHR means a better performance by the cache removal scheme, and a reduced time can be achieved to deliver the requested content. After each content request, every server node calculated its CHR using (10). \[CHR_{n}=\frac{\sum_{i=1}^{m}(CacheHit_{i})}{\sum_{i=1}^{m}(CacheHit_{i})+ \sum_{i=1}^{m}(CacheMiss_{i})}\times 100\% \tag{10}\]  
Here, \(m\) is the total number of content requests at a server node \(n\) and \(CHR_{n}\) is the Cache Hit Ratio of that server node. \(\sum_{i=1}^{m}(CacheHit_{i})\) is the total number of requests where the requested content was readily available at the corresponding server node \(n\). On the other hand, \(\sum_{i=1}^{m}(CacheMiss_{i})\) is the total number of requests where the requested content was not readily available at the server node \(n\); hence the requested content had to be fetched from the other server nodes. The CHR was converted into a percentage figure. The performance of the proposed CPR-based cache removal scheme was compared in terms of CHR with two other cache removal schemes: LRU and LFU. As in the previous section, all these schemes were implemented separately within the CCN architecture for the experimental results of this subsection. The proposed CPR-based cache removal scheme keeps recurrently requested popular content in the repository for as long as possible and removes less popular content when there is a lack of space in the storage. However, the LRU scheme removes content that was not requested in times when there is not enough space for caching new content. By comparison, the LFU scheme removes content that was requested the lowest number of times. Both of these schemes have a higher possibility of removing content that can be requested sooner than later, as they do not consider the potential future popularity of that content. The results of the experiments in terms of CHR are demonstrated in Figure 3. In this graph, the maximum amount of available content within the network was varied, keeping the size of the cache repository fixed at 70 MB, and one server could handle a maximum of 7 clients at a time. The performance trend in terms of CHR was similar while we varied these two parameters. The \(Y\)-axis indicates CHR values, and the \(X\)-axis shows the maximum amount of available content within the network topology. The server nodes had nearly 99% CHR when the total number of available pieces of content was only 10, as the total size of the stored content almost always remained lower than the capacity of these servers. Therefore, some cache misses occurred at the beginning of the experiment, and only a few other cache misses happened during the whole experiment. As the number of content pieces increased, more cache overflows started to occur, and CHR began to decrease.