Popularity Ranking Algorithm Evaluation

In Section4.9.3.1we introduced our take on an iteration of an edge-related popularity ranking algorithm with the goal of choosing the most relevant item to offload to the infrastructure during every popularity decision cycle to be cached in theLocal Popularity Cache for easier access. By considering its characteristics, it is possible to presuppose some of the potential positive impacts on the performance of the system: a higher cache hit ratio on theLPC since only the items considered relevant by the algorithm are marked to be cached by the infrastructure; a lower transmission of download requests to the mobile nodes due to the algorithm limiting the number of items to download during each execution as well as ignoring items that, while still possessing popular traits, are no longer considered active, ultimate saving these nodes’ resources.

Nonetheless, due to our role as researchers throughout the duration of this disserta-tion, it is imperative to put our algorithm to the test in order to collect palpable metrics to confirm the validity of our assumptions. Therefore, in this evaluation scenario, we focused on testing the popularity ranking algorithm and comparing its results to the same system execution but, this time, the T h y m e - I n f r a node will not utilize any pop-ularity ranking algorithm and will choose to download all items, without filter, from its local clients. Consequently, in both cases, we tracked the number of download requests initiated by the infrastructure with the goal of offloading items into its Local Popularity Cache as well as its hit ratio.

As a consequence of the asynchronous eviction nature of the Caffeine cache, which is used in theLPC, we executed the 100-nodes trace in its original duration, 720 minutes, to offset any misleading results caused by the library’s approach which would be more common in the reduced simulation time:

“By default the (eviction) policy work is performed asynchronously (...). After a read or write, an operation is appended to a bounded queue and draining this queue is sched-uled on an executor. For reads this occurs after a threshold while writes are immediate.

1 5 10 15 20 25 30 0

100 200 300 400 500 600 700

Popularity Decision Cycle

MobileItemsRequested

No Popularity Ranking Algorithm Popularity Ranking Algorithm

Figure 5.5: Number of mobile items requested by the infrastructure per popularity deci-sion cycle when using a popularity ranking algorithm versus no algorithm at all.

This causes the maximum (size) to be exceeded temporarily (...).” [70]

Furthermore, we deployed a single T h y m e - I n f r a instance and chose the first 30 decision cycles to analyze.

Fig. 5.5presents the number of requests initiated by the infrastructure during each Popularity Decision cycle, in both scenarios, throughout the execution of the trace. While in the first few cycles the outcome is essentially the same (i.e. both are filling the cache while it is not full), subsequent cycles for the scenario without the popularity algorithm showcase, as expected, a constantly increasing amount of item requests that follows the rate of which new items are published in the network. Yet, by utilizing our proposed popularity ranking mechanism, the number of infrastructure requests starts to stabilize after the cache is full and gradually performing small adjustments to the cache’s contents throughout the trace, never requesting more than 70 items at any given cycle.

On the other hand, Fig.5.6shows that theLCP hit ratio during the scenario with the popularity ranking algorithm presents far better results, namely a 10% increase, than when not using it.

Thus, we conclude that even with our coarser approach to calculating file popularity, we are able to provide a better storage utilization — measured by the cache hit-ratio

— through an acceptable amount of file requests per popularity decision cycle, when comparing to the alternative unbounded approach. We can further correlate this findings with a lower battery and processing utilization from the mobile nodes, as we are able to reduce the amount of times items are mindlessly offloaded into the infrastructure while still successfully serving 42% of the received download requests, which would have to be processed by mobile replicas otherwise.

No Popularity Ranking Algorithm

Popularity Rank-ing Algorithm 0

10 20 30 40 50

LPCHitRatio(%)

Figure 5.6:Local Popularity Cache hit ratio comparison between using a popularity rank-ing algorithm to decide which items to offload and no algorithm at all.

5.3.3 Adaptive Multipart Caching

TheAdaptive Multipart Caching approach is at the core of T h y m e - I n f r a in providing a more flexible caching partitioning system which accommodates to the users’ needs on-the-fly, with the goal of optimizing the storage utilization of the infrastructure node.

In this testing environment, we focused on tracking the behavior of the AMC algo-rithm across multiple population scenarios to verify that it worked as it was originally intended to do so, i.e. the attributed world cache partition size matches its users interac-tion rate. Consequently, to create these distinct scenarios, we generated various iterainterac-tions of the 100-nodes trace file and created 3 different worlds, wherein all nodes were evenly distributed across them. Furthermore, in each iteration, we altered the base rate at which publications were executed by the clients to artificially increase the popularity/intensity in a world-by-world basis to promote disparities between them.

Fig. 5.7 shows theLocal Popularity Cache occupation (%) of each world at the end of the trace, as a consequence of the continuous execution of the AMC algorithm, for different popularity rates, where 1/1/1 indicates the baseline popularity for all worlds while 2/1/1 expresses that “World 1” is twice as popular than the rest of the worlds (i.e.

double the number of publish operations, per hour in real-time).

As we can assert from the observed results, theAMC provides an equivalent size to all inner caches when each world’s population presents an identical degree of popularity.

On the other hand, when this equality is deteriorated and disparities are introduced into the worlds’ needs, theAdaptive Multipart Caching is able to adapt and provide an higher cache size to the more demanding populations by reducing the size of the remaining containers as a consequence of this, for instance: the world 1 size was increased from 34%

in 1/1/1 to 72% in 2/1/1 while the world 2 and 3 suffered a reduction of 24% and 16%, respectively.

Therefore, from a pragmatic standpoint, the AMC procedure is working as it was

1/1/1 2/1/1 2/2/1 5/1/1 0

20 40 60 80 100

Worlds’ Publish Execution Rate

WorldLPCOccupation(%)

World 1 World 2 World 3

Figure 5.7: Outcome of the Adaptive Multipart Caching mechanism for worlds with dis-parate population needs.

originally intended, i.e. giving more cache real state to worlds with an increased popu-larity while reducing the size on the other end of the spectrum. Yet, points can be made about improving the algorithm, especially in scenarios where one of the worlds display an overwhelming popularity when compared to the rest of the system (as seen in the 5/1/1 scheme). Since the rest of the worlds are only able to amass one to two percent of the main cache’s total size due to their contrastingly low needs, the partitioning system could employ additional features to tackle scenarios like this one:

• A predetermined lower bound to each world’s cache size to offset the negative im-pacts of an overwhelming world, with the goal of ensuring that every distinct pop-ulation will have a minimum guarantee that some of their items will be offloaded and served by the infrastructure;

• Another alternative implementation would approach this the other way around, by imposing a minimum amount of entries that each world needs to have before being completely evicted from the cache. This could present an acceptable tradeoff if moving the 1-2% capacity from the lowest caches into the bigger ones would result in an overall higher traffic and battery consumption reduction to the mobile nodes.

However, due to time constraints, we were not able to perform and build such supple-mentary tests and features.