Seamless and adaptive application-level caching

Meeting performance and scalability requirements while delivering services is a critical issue in web applications. Recently, latency and cost of Internet-based services are encouraging the use of application-level caching to continue satisfying users' demands and improve the scalability and availability of origin servers. Application-level caching, in which developers manually control cached content, has been adopted when traditional forms of caching are insufficient to meet such requirements. Despite its popularity, this level of caching is typically addressed in an ad-hoc way, given that it depends on specific details of the application. Furthermore, it forces application developers to reason about a crosscutting concern, which is unrelated to the application business logic. As a result, application-level caching is a time-consuming and error-prone task, becoming a common source of bugs. Among all the issues involved with application-level caching, the decision of what should be cached must frequently be adjusted to cope with the application evolution and usage, making it a challenging task.

Application-level caching is mainly characterized by caching techniques employed along with the application code, i.e. business, presentation and data logic. Therefore, it is not tied up to a specific caching location (server-side, proxy or client-side), because it can be conceived at the server-side, to speed up a Java-based application that produces HTML pages sent to users, as well as at the client-side, as a JavaScript-based application that executes part of its logic directly on the client's browser. In both situations, developers can reason about caching and implement a caching logic to satisfy their needs.

Evaluation set up - Identifying cacheable methods automatically

Simulations were performed using three different caching configurations: (i) no application-level caching (NO), (ii) application-level caching manually designed and implemented by developers (DEV); and (iii) our approach (AP).

Summary

• Three applications
• Three set ups for each application: NO, DEV, AP
• A simulation of a randomized workload for each set up

Folders

• aplcache: source code of the framework
• evaluation/applications/AP: contains all the applications with APLCache configured
• evaluation/applications/DEV: contains all the applications with manually configured caching
• evaluation/applications/NO: contains all the applications with no caching
• evaluation/applications/databases: database dumps for each application
• evaluation/applications/understand: static software metrics collected with Understand software
• evaluation/workload: simulation of a randomized workloads for each application

Required Tools

• Jmeter 3.3 - not tested with newer versions
• Jmeter Plugins - install the plugin manager and plugins when required after loading the workload scripts
• MySQL 5.5 or newer
• Java 8 - not tested with Java 9 or 10
• Maven 3 or newer

Applications

To prevent application bias in our results, we selected applications with different sizes (6.3--111.3 KLOC) and domains.

Our evaluation was performed with three open-source web applications:

• Cloud Store
• Spring petclinic
• Shopizer

Compiling and using APLCache

• In the source of APLCache (aplcache) run: mvn clean install

Shopizer:

This application requires the installation of Elasticsearch (https://www.elastic.co/) to run properly. You can use the docker image below to run elasticsearch:

docker pull docker.elastic.co/elasticsearch/elasticsearch:6.5.2
docker run -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" docker.elastic.co/elasticsearch/elasticsearch:6.5.2

Installation and configuration:

• Create schema SALESMANAGER on the database
• Configure the file database.properties with your database info
• Restore the dump of the database located in evaluation/applications/database/shopizer.sql
• [OPTIONAL] You can also generate new data: in the file shopizer-properties.xml there is the tag true. For AP and DEV, such configuration will provide 7 categories, 6 products, addresses USA, one customer, one admin, shipping info in the database in the first initialization of the system. For NO, it will be generated a lot of more randomized data. For more information on how the database is populated, please refer to InitData.class and its implementations.
• Compile at the root folder: mvn clean install -DskipTests
• Run in the folder sm-shop with mvn tomcat7:run-war

Use the urls below to access system's features:

• http://localhost:8080/sm-shop/shop → Store page
• http://localhost:8080/sm-shop/admin → Administration page where the login and password are: admin:password

Petclinic

Installation and configuration:

• Create schema petclinic on the database
• Configure database on the file pom.xml
• Restore the dump of the database located in evaluation/applications/database/petclinic.sql
• Compile and run: mvn clean install tomcat7:run-war -DskipTests
• Url to access the system: http://localhost:8080/petclinic/

CloudStore

Installation and configuration:

• Restore the dump located in evaluation/applications/database/cloudstore.sql, such dump has 10000 books
• Configure database on file src/main/resources/database/database.hibernate.properties
• Compile and run: mvn clean install tomcat7:run-war -DskipTests
• Url to access the system: http://localhost:8080/showcase/

Simulations

Our simulation emulated client sessions to exercise applications and evaluate decision criteria. Simulations consisted of 50 simultaneous users constantly navigating through the application, at a limit of 1000 requests per user.

Each emulated client navigates from an application page to another, randomly selecting the next page from those accessible from the current page. The navigation process starts on the application home page. Emulated clients thus follow the same navigation rules of a real user.

After run the application, JMeter is used to simulate load. Thus, open Jmeter, load the simulation setup according to the application that should be evaluated.

Metrics

To assess performance, we used two metrics: throughput (number of requests handled per second) and hit ratio, because they are well-known in the context of web applications and cache performance tests.

• Throughput is obtained from Jmeter reports
• Hit absolute and Hit ratio can be acquired from jconsole after the end of the simulation. Such metrics will be presented at EhCache → Estatistics →