Generic Cache

Enhancing QoS in a University Network by using Containerized Generic Cache

        
        hyperyolo ~ $ 
        hyperyolo ~ $ 
        root@linuxcache ~ $ 
        root@linuxcache ~ $ 
        hyperyolo ~ $

About

Ubiquitous access and enhanced Internet speeds have paved ways for online educational reforms at a large scale. There has been a widespread adoption of modern educational applications, ranging from interactive applets, video lessons and online quizzes to remotely conducting laboratory experiments. Consequently, there is a demand to provision more bandwidth to satisfy users expectations. Generic Cache is an approach to enhance the Quality of Service (QoS) in a University campus network and efficiently utilize the available bandwidth.

Typically within an University, some requests are similar, e.g., operating system updates, Linux package installs, Python pip packages and others. These are huge data transfer requests ranging from Megabytes to Gigabytes, and consume a large amount of bandwidth on external access links to the Internet. Redundant requests of this nature from a large user base lead to enormous wastage of bandwidth.

Generic Cache overcomes this concern by setting up a containerized forward proxy function as a cache for popular traffic in the University. A large number of redundant requests can be successfully served from this Virtualized Network Function (VNF), thereby enhancing the QoS and efficiently utilizing the available bandwidth. Since this cache is implemented as a VNF, it is portable and easy to deploy.

The features of Generic Cache are outlined below:

Rapid setup

Start using Generic with just couple of lines of shell commands on any system. Due to the "Generic" nature, it can be used to cache multiple webistes without any changes to config/setup process.

Robust monitoring

Analyse the performance of the system in the network in real-time. Also get detailed stats if required

Secure

Generic cache is as secure as the Gateway used in network. It has also been quality tested against fishing and DDOS attacks.

Configurability

Generic cache is extremely configurable. To make things more robust Generic cache also provides regex parsing out of the box. All these configuration are in a single file and can easily be changed anytime

Portability

Generic Cache is implemented as a VNF and thus is portable (both data and process) from one system to another with ease.

Automated data management and logging

Generic Cache out of the box has automated data management service (which uses LRU strategy) and logging mechanisms for all the collected stats.

Read our documentation for more detailed information

Documentation

Performance statistics

Generic Cache has been deployed in NITK since Jan 2019. The following graphs depict the performance of the system when fuctioning as a Cache for "Ubuntu" over a period of 1 month. The Deployed system has proven to be robust in performance in an instituion with over 12k strudents. It has also proven to save significant amounts of data each day and also considerably imporving the speed of internet.

The following is a graph shows the overall Miss and Hit ratio of the cache.

From the following graph, we can clearly note that the cache stabilised at 83% of HIT ratio ratio and 14% MISS ratio within a week’s worth of time.


The following is a graph shows total traffic recieved and the bandwidth saved on each day

From the following graph, we can see that we are able to save about 34GB of data each day by just caching one website.


The following tables show the performance of Generic Cache w.r.t Latency and Cuncurrency relative to the origin server.

From the following tables, show a clear reduction in latency and increase in availability, throughput and concurrency as compared to the origin server. This improvement is both due to the higher bandwidth of the internal LAN and the significantly smaller size of audience the cache server has to respond at a time, when compared to that of the origin servers.


Table showing the Latency measured
Server Thread stats Avg Stdev Max +/- Stdev
Cache Server Latency 74.21ms 314.04ms 6.16s 95.92%
Req/sec 27.00 1.00 28.00 100.00%
Transfer/sec 98.35KB - - -
Origin Server Latency 194.47ms 26.13ms 606.21s 93.10%
Req/sec 25.25 14.83 46.00 77.36%
Transfer/sec 83.86KB - - -
Table showing the Concurrency achieved
Server Measured quantity Result
Cache server Transactions 1697 hits
Availability 100.00%
Response time 1.65 sec
Transaction rate 58.30 trans/sec
Concurrency 96.00
Longest transaction 7.56
Origin server Transactions 312 hits
Availability 86.19%
Response time 4.16 sec
Transaction rate 10.61 trans/sec
Concurrency 44.10
Longest transaction 9.71