Automation of Application-level Caching in a Seamless Way

Given that web caching is strictly related to the web infrastructure components, we overview such architecture in Figure 1 together with the primary caching locations. Caching solutions at the web infrastructure can be grouped into three main locations: client, Internet, and server [6, 7, 8]. In short, the client component is essentially the client’s computer and web browser; while the Internet component contains a wide range of different, interconnected mechanisms to enable the communication between client and server. The server can include multiple and different servers that are collectively seen as the web server by the client [8].

Each caching location has its benefits, challenges, and issues that together lead to trade-offs to be resolved when choosing a caching solution. For instance, particular forms of content can be cached according to a selected choice of location as well as the abstraction level provided, which can be fully transparent to the application or tightly integrated into the application code. In addition, hit and miss probabilities vary across different locations [4, 9, 10, 1, 11, 12]. Due to the variety of application domains, workload characteristics, and access patterns, no universal web caching solution outperforms other caching options in all possible scenarios. Therefore, caching at these different locations is complimentary.

Application-level caching resides on the server side. As opposed to traditional caching alternatives, which are transparent to the application, application-level caching is tightly integrated into the application base code. It becomes needed in modern web applications because they manipulate and process customized content and, in this case, caching final web pages provides limited benefits. Therefore, application-level caching can be used to separate generic from customized content at a fine-grained level.

As an example, we present in Figure 2 a scenario in which application-level caching is used to lower the database workload. In this example, an e-commerce application has a ProductsRepository class, which is responsible for loading products from the database. First, the web application receives a request for all the products from a user (step a), which eventually leads to an invocation to the ProductsRepository class. However, such class makes a database query on DBAccess, and calling and executing DBAccess may imply an overhead regarding computation or bandwidth. Therefore, ProductsRepository manages to cache DBAccess results and, for every request, ProductsRepository verifies whether DBAccess should be called or there are previously computed results already in the cache that can be used (step b). Then, the cache component performs a look up for the requested data and returns either the cached result or a not found error. If a hit occurs, it means the content is cached, and ProductsRepository can avoid calling DBAccess. However, when a miss occurs and then a not found error is returned, it means that DBAccess computation is required (steps c and d). The newly fetched result of DBAccess can then be cached to serve future requests faster. These steps, described in Figure 2(b), are those typically performed in any cache implementation. The key difference is that, in application-level caching, the responsibility of managing the caching logic is entirely left to application developers, who must manually handle the cache.

In this scenario, caching decisions are made explicit, which involves many issues [13]. The first is that developers must manually develop and insert the caching logic into the application base code, which involves content retrieval and translation as well as key assignment and consistency maintenance. Such logic is usually tangled with the business logic—as illustrated in Figure 2(a)—and making the caching code a cross-cutting concern, i.e. it is spread all over the application base code, resulting in increased complexity and maintenance time [1].

Furthermore, such implementation requires developers to make caching decisions, such as choosing which objects to get, put or remove from the cache. Such decisions demand a significant effort and reasoning from developers because they need to understand what are the typical usage scenarios, how often the content selected to be cached is going to be requested, how much memory it consumes, and how often it is going to be updated. These are all non-trivial decisions [13].

Caching implementation can be supported by available libraries and frameworks, which provide implementations of a cache system, e.g. Caffeine¹¹1https://github.com/ben-manes/caffeine, EhCache²²2http://www.ehcache.org/ and Memcached³³3https://memcached.org/. Although there are existing tool-supported approaches that raise the abstraction level of caching and prevent adding much cache-related code to the base code [14, 1], caching decisions such as determining what should be cached remains as a developer responsibility.

A fundamental problem of application-level caching is that all issues above usually demand extensive knowledge of the application to be properly solved. Consequently, developers manually design and implement solutions for all these mentioned tasks. However, even when adopting a caching solution to improve the application performance, the issues and challenges concerning maintenance remain unaddressed. While designing and implementing application-level caching, developers usually specify and tune cache configurations and strategies according to application specificities. Nevertheless, an unpredicted or unobserved usage scenario may eventually emerge. As the cache is not optimized for such situations, it would likely perform sub-optimally [3]. As a result, to achieve caching benefits so that the application performance is improved, it is necessary to tune cache decisions continuously [15].

This shortcoming motivates the need for adaptive caching solutions, which could overcome these problems by automatically adjusting caching decisions according to the application specificities to maintain a required performance level. Moreover, an adaptive caching solution minimizes the challenges faced by developers, requiring less effort and providing a better experience with caching.

Although application-level caching is commonly being adopted, the selection of cacheable content is typically an ad hoc and empirical process. To find caching best practices, developers can make use of widespread knowledge, consult development blogs, or simply search online for tips. Nevertheless, this knowledge is unsupported by concrete data or theoretical foundations that demonstrate its effectiveness in practice. Thus, developers usually implement the necessary cache logic for the assumed cache opportunities and evaluate the performance improvement empirically based on benchmarks and application executions.

Given this scenario, in previous work [13], we analyzed how developers deal with application-level caching. This work allowed us to derive a set of patterns that capture criteria used to make cache-related decisions, giving practical guidelines for developers to appropriately design caching in their applications. One of such patterns, namely the Cacheability Pattern, focuses on the selection of cacheable content, more specifically method calls, and is specified in a flowchart, presented in Figure 3.

Although such pattern is conceived to reuse, it is an abstract solution that requires specific reasoning and coding to make use of it. In real-world situations, developers should reason about application specificities and decide whether to cache or not a specific method regarding the criteria. No objective measurement to evaluate whether a method satisfies each criterion has been provided. Therefore, although such an approach systematizes the decision regarding content cacheability, developers must still have knowledge of the application requirements, workload, domain, access patterns and business logic as well as manually select content to be cached.

Our approach is based on the decision process presented in Figure 3, which gives the criteria to be taken into consideration to make caching decisions. For each criterion, we propose objective means of measuring application methods and evaluating whether they should be cached. This evaluation is based on data collected by monitoring the workload of web applications at runtime. Furthermore, our automated approach takes into account application-specific details in caching decisions, which is, in fact, the information considered by developers in the development of a caching solution, thus providing a solution that is specific and optimized to the problem of selecting cacheable content. By providing an automated approach, we relieve developers from the process of instantiating that abstract solution according to their specific domains or characteristics.

Our proposed solution can be incorporated into web applications so that it can monitor and choose content to be cached according to changing usage patterns. It consists of two complementary asynchronous parts: (a) a reactive model applying, responsible for monitoring traces of the application execution and caching method calls (previously identified as caching opportunities) at runtime; and (b) a proactive model building, which analyzes on the background the behavior of the application, taking into account application-specific information, and finds cacheable opportunities. Figure 4 presents an overview of the dynamics of our approach, indicating the activities that comprise its running cycle. These asynchronous parts involve performing three different activities: (1) data tracking, (2) data mining and (3) cache management.

Because our approach monitors the application at runtime and self-optimize caching decisions, it is sensitive to the evolution of application workload and access patterns. This addresses the main problem regarding cache maintenance because it forces developers to revise their cache decisions constantly. Moreover, the integration between our approach and the application is seamless and does not require manual inputs, detaching caching concerns from the application and providing higher cohesion and lower coupling. As result, our approach can reduce the reasoning, time and effort required from developers to develop a cache solution, allowing them to dedicate time to write the most relevant code (i.e. business logic). If full automation is not desired, our approach can alternatively serve as a decision-support tool to help developers in the process of deciding what to cache, guiding them while manually implementing caching.

We next conceptually describe each activity of our approach. Later, we show how they are operationalized within an implemented framework.

As opposed to traditional caching approaches, which cache content such as web pages or database queries, our approach focuses on caching method-level content. Moreover, we use application-specific information to make caching decisions, such as the user session, execution time of method calls, and data and cache sizes.

To monitor the application behavior, we collect method invocations or calls (i.e. application execution traces) at runtime. Related to this monitoring process, two issues must be addressed. First, we must specify what information should be recorded when invoking methods. Second, given that the monitored and recorded information may be a complex structure, it is essential to provide means of dealing with such complexity.

Concerning the first issue, we adopt a lightweight and conservative approach. It is lightweight because it is based on recording just the input and output of each method call. As stated by Toffola et al. [5], recording detailed information before and after each method call does not scale to large web applications with a high number of concurrent users. Thus, we focus on information regarding the arguments passed to the call and the return value of the call (if any), because this information is sufficient to describe the relevant input and output state for most of the methods. The monitoring process is also conservative in the sense that the recorded information is the complete method call, consisting of the method identification (i.e. its signature), the values of all method inputs, its output (i.e. its returned value), and additional information, namely cost and user session.

Each recorded method call is a tuple

where $s$ is the representation of the target of the call, $P=[p_{1},\dots,p_{n}]$ is a list of parameters of the call, $r$ is the returned value, $c$ is the cost of computing the method, and $u$ is the user session associated with the method call. The cost can be the time taken to execute the method, memory consumed, or any other developer-specified resource.

Finally, these method calls are mapped into a generic representation that is saved as a string. The representation describes the data itself and the shape of the data item. The representation captures the structure of objects and is independent of the memory locations where objects are stored or other globally unique identifiers of objects. Figure 5 gives an example of how a method call is mapped into a record.

The second activity of our approach takes as input the output of the previous activity (data tracking), which provides us with information needed to identify methods to be cached. To decide what should be cached, the second activity is based on the mining of such information.

As said, the reasoning part of our automated approach is based on the decision process presented in Figure 3. This reasoning model specifies a sequence of questions to be answered that are associated with criteria to be analyzed. By chaining different decisions taking into account each criterion, an importance relationship among them is established. Content changeability is the first analyzed criterion, followed by usage frequency, shareability, retrieval complexity, and size properties. However, given the pattern was conceived to be used at design time, using it at runtime requires adaptations to be made.

These adaptations concern the size-related criteria, which make more sense at design time, because developers may not have enough information to predict the size required to store a particular piece of content and the size available in the cache. Consequently, in this case, some data may be chosen as not cacheable. However, at runtime, it is possible to know the size of the content to be cached as well as the available cache size and occupation ratio.

Therefore, using size-related criteria to decide, at runtime, what to cache (as suggested by the Cacheability pattern) can lead the cache to a non-maximum utilization, i.e. cacheable methods could be classified as uncacheable even with enough free space in the cache. To avoid this, we use the size-related information to decide whether a cacheable method should be put in the cache. Consequently, we do not consider the size-related criteria in the identification of cacheable method calls in the data mining activity, but they are taken into account in the next activity. As result, we obtain a simplified reasoning process to be automated and used while identifying cacheable content, which is presented in Figure 6.

To be automated, this process needs to have its decision criteria analyzed to make decisions. However, in the Cacheability Pattern, there are no objective definitions. This means that, when adopting this pattern, developers must provide a meaning for each criterion. We thus, as part of our approach, propose objective measurements to evaluate each criterion. There are five specified measurements, which are detailed in Table 1.

Essentially, the objective evaluation is a statistical analysis of collected traces. All the information required by each criterion is presented in Table 2. Note that due to a limited amount of data—such as considering a method with only a few executions as static, frequent, or less changing—wrong conclusions can be reached. Therefore, in situations in which we have an insufficient amount of data, we assume Undefined as the result of the criterion analysis.

Based on our objective criteria evaluation and the simplified decision process, our approach identifies cacheable methods. It is important to note that one method may result in many cacheable opportunities (and consequently many entries in the cache) because our approach distinguishes and analyzes method calls, which are specified as a combination of the method signature and parameter values. In the next activity, described as follows, we detail how we cache method calls defined as cacheable opportunities, using the two remaining criteria, not taken into account in this activity.

With the previous activities, we identify a set of cacheable method calls. We now discuss how our approach manages the cache component to cache the selected method calls as well as to keep consistency. Similarly to the data tracking activity, through monitoring the application execution, we intercept calls to cacheable methods and assess whether the content associated with the call is in the cache.

As our approach solely learns whether method executions should be cached, other cache concerns, such as eviction and consistency, were addressed with standard solutions. To make our approach less dependent on the effectiveness of alternative cache policies and algorithms, as a default configuration, we suggest a conservative approach that caches content only when there is enough space in the cache, considering the data size and cache size, the two remaining decisions of the Cacheability pattern, which are presented in Table 3. Moreover, to periodically free space in the cache and remove outdated content, a time-to-live (TTL) should be specified. With TTL, cached methods expire after a time in cache, regardless of possible changes. This frees cache space for caching new content associated with cacheable methods. In addition, TTL is a popular solution to deal with consistency issues, which requires to relax freshness and admit potential staleness to increase performance and scalability.

During the execution, when a cacheable method is called and the returned content is not in the cache, we estimate how much space of the cache this method call requires and verify whether the cache has the corresponding free space to allocate such content. If there is no enough space in the cache, no content is cached until TTL expires cached data. It is important to note that cache size and TTL are both domain-specific and have no relation to the identification of cacheable content. Thus, these values should be manually specified when instantiating our approach.

As stated in the introduction, our primary objective while proposing this approach is to provide automation and guidance to developers when adopting application-level caching in their applications. This approach aims to provide such guidance using an automated and seamless application-centric approach, i.e. by identifying cacheable opportunities in their applications, taking into account application details. The evaluation of our approach is based on the goal-question-metric (GQM) approach proposed by Basili et al. [16]. The GQM was adopted to define the goal of the evaluation, the research questions to be answered to achieve the goal and metrics for responding to these questions. Following this approach, we present in Table 4 the description of the evaluation, following the GQM template. To achieve our goal, we investigated different aspects of our automated approach, which are associated with three key research questions presented in Table 5 along with their metrics.

Given that caching is essentially a technique to improve performance and scalability, RQ1 concerns evaluating this. Although our approach relieves the developer from this task, it still needs to provide performance improvements. Determining the cacheable content and the right moment of caching or clearing the cache content are a developer’s responsibility and might not be trivial in complex applications. In RQ2, we aim to identify what methods were considered caching opportunities and how they can be compared to the choices manually made by developers.

To evaluate our approach, we used performance test suites, which aim to simulate real-world workloads and access patterns [17]. Furthermore, these tests have been used to evaluate improvements of caching in web applications [5, 2].

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). To assess performance, we used three metrics: throughput (number of requests handled per second), hit ratio and the total number of hits, because they are well-known in the context of web applications and cache performance tests.

Our simulation emulated client sessions to exercise applications and evaluate decision criteria. Simulations consisted of variations of 1, 5, 10, 25 and 50 simultaneous users constantly navigating through the application, always at a limit of 500 requests per user. Each simulation was repeated ten times, and the mean of each metric was collected. Each emulated client navigates from an application page to another, selecting the next page from those accessible from the current page, to better represent a real user. The navigation process starts on the application home page and follows a non-uniform random selection that falls into a distribution where 80% of the requests are read-only, while the remaining 20% perform at least one write operation. This distribution is mentioned in standard performance benchmarks such as TPC-W⁶⁶6http://www.tpc.org/tpcw/ and RUBiS⁷⁷7http://rubis.ow2.org/index.html.

The evaluation of different criteria requires different parameters. We used a web application, not used in our evaluation, to empirically choose these parameters. As result, we adopted 99% and 3% as the confidence level and margin of error, respectively, for the frequency criterion. For shareability and expensiveness, we adopted $k=1$, while for changeability, $k=0$. For expensiveness, the cost corresponds to the method execution time.

For all the executions of AP, caches were bounded by a cache size and configured with a TTL, which were both specified and used by developers of our target systems (DEV). As the results may be influenced by the cache policy adopted, in addition to our standard technique based on TTL, we also evaluated our approach combined with popular replacement policies, namely least recently used (LRU) or least frequently used (LFU). Finally, we used information collected over 2 minutes to build the caching decision model in AP scenario.

Our evaluation was performed with three open-source web applications⁸⁸8Available at http://www.cloudscale-project.eu/, https://github.com/SpringSource/spring-petclinic/ and http://www.shopizer.com/., presented in Table 6, which summarizes the general characteristics of each target system. To prevent application bias in our results, we selected applications with different sizes (6.3–111.3 KLOC) and domains. Cloud Store, in particular, is developed mainly for performance testing and benchmarking, and follows the TPC-W performance benchmark standard. It is important to highlight that the DEV configuration was implemented by developers independently from the results of our previous work [13] and, therefore, the Cacheability Pattern was not considered in this implementation.

For Pet Clinic and Cloud Store, we used test cases written by their developers and developed test cases for Shopizer, for which they are unavailable. For the latter, we created test cases to cover searching, browsing, adding items to shopping carts, checking out, and editing products.

We used Tomcat⁹⁹9http://tomcat.apache.org/ with 2G RAM dedicated its JVM as our web server and MySQL¹⁰¹⁰10https://www.mysql.com/ as the DBMS. We used two machines located within the same network, one machine for the DBMS and web server (16G RAM, Intel i7 2GHz), and one machine for JMeter¹¹¹¹11http://jmeter.apache.org/ (32G RAM, Intel i7 3.4GHz). The selected underlying caching framework is EhCache because it is used in all target applications. Moreover, we also used the same cache component configurations (TTL and in-memory cache size) as specified by developers in each application. Regarding the TTL implementation and its operation, we rely on the default behavior provided by the chosen cache provider.

We now analyze the threats to the validity of our empirical evaluation. First, the performance benefits of caching highly depend on workloads. Consequently, it is possible that the adopted workload from the performance tests may not be representative enough, given that we do not make any assumption regarding the workload when conducting our experiments and rely on the randomness added to the tests. Nevertheless, our approach does not depend on a particular workload and can find cacheable methods with any pre-specified workload, which may evolve over time in real world scenarios. Therefore, even if the workload changes substantially and initial cacheable methods are no longer useful, our approach can adapt itself, automatically discarding old caching configurations and discovering a new set of cacheable methods. Second, our evaluation involves only three target applications. Therefore, results may not be generalizable. To address this threat, we selected open-source applications, with different sizes and domains, implemented by different developers.

A research challenge in application-level caching is how to reduce the burden of implementing application-level caching from developers. As a consequence, implementation-focused approaches have been extensively proposed. These solutions can raise the abstraction level of caching and reduce a significant amount of cache-related code to be added to the base code.

These approaches take the form of supporting libraries and frameworks, providing useful and ready-to-use cache-related features. However, such solutions require code changes and a manual integration with web applications to exploit caching benefits i.e. developers are responsible for managing the cache. Examples of such solutions are distributed cache systems, e.g. Redis¹³¹³13https://redis.io/ and Memcached, and libraries that cache content locally, e.g. Spring Caching¹⁴¹⁴14https://docs.spring.io/spring/docs/current/spring-framework-reference/html/cache.html, EhCache, Infinispan¹⁵¹⁵15http://infinispan.org/, Caffeine and Rails low-level caching¹⁶¹⁶16http://edgeguides.rubyonrails.org/caching_with_rails.html#low-level-caching. In addition, as caching is essentially a cross-cutting concern [19], aspect-oriented programming (AOP) [20] have been explored in order to provide a flexible and easy-to-use solution, such as Jcabi-aspects¹⁷¹⁷17http://aspects.jcabi.com/annotation-cacheable.html.

The drawback of traditional supporting libraries and frameworks is partially addressed by approaches that provide developers with ways to declare knowledge associated with the semantics of application code and data through annotations in the code, and then specific caching tasks are automated. Such solutions have a lower impact on the application, as it does not require to introduce code interleaved with its base code. For example, CacheGenie [14] and TxCache [1] provide cache abstractions based on a specific and simple declarative programming model where developers can indicate the methods that should be cached. Then the proposed approaches can automatically cache and invalidate the results. Similarly, Huang et al. [21] proposed a browser-side caching framework that allows developers to customize their caching strategies, such as expiration times, cache granularity, and replacement policies.

Totally seamless and transparent solutions are usually coupled to the application as a surrounding layer, such as database [7] or proxy-level [22] caching approaches. In this context, EasyCache [23] is a hybrid solution that combines properties of database caching and application-level caching to provide transparent cache pre-loading, access and consistency maintenance without extensive modifications to the application or a complete redesign of the database. Similarly, AutoWebCache [19] can also be seen as a hybrid approach that associates the back-end databases and the dynamic web pages at the front-end. AutoWebCache uses AOP with pre-defined caching aspects to add caching of dynamic web pages to a servlet-based web application that interfaces a database with JDBC, managing consistency between such components through effective cache invalidation policies.

Although implementation-centered approaches can raise the abstraction level of caching, they still demand cache reasoning on developers, such as deciding whether to cache content.

As mentioned before, application-level caches allow arbitrary content to be cached, and opportunities for caching thus emerge in the most diverse parts of the application. A popular approach to support developers while admitting content to the cache is to recommend caching opportunities. In this context, application profiling is usually the technique adopted, such as in MemoizeIt [5], which compares inputs and outputs of method calls and gives a set of redundant operations. To avoid comparing objects in detail, MemoizeIt first compares objects without following any object references, and then iteratively increases the depth of exploration while shrinking the set of considered methods. Also by analyzing method calls, Maplesden et al. [24] proposes an approach that analyzes the smallest parent distance among common parents of a method to identify repeated patterns, which are named subsuming methods.

Xu [25] addresses the problem of frequent creation of data structures, whose the lifetimes are not connected, but the content is always the same. Then, a list of top allocation sites that create such data structures are reported. Similarly, Cachetor [26] addresses repeatedly computations by providing a runtime profiling tool that uses a combination of dynamic dependency and value profiling to suggest spots of invariant data values.

Although these approaches can potentially relieve reasoning burden from developers, such recommendations should be analyzed and implemented by them, integrating the appropriate cache logic into the application. Thus, approaches that identify but also automate the caching of cacheable content have been proposed. However, besides the analysis of the application behavior, such approaches also employ mechanisms to manage cache and application at runtime.

In this context, IncPy [27] achieve this by implementing a technique as a custom open-source Python interpreter. IncPy explores the repetitive creation and processing of intermediate data files, which should be properly managed by developers to multiple dependencies between their code and data files. Otherwise, their analyses produce wrong results. To enable developers to iterate quickly without needing to manage intermediate data files, they added a set of dynamic analyses to the programming language interpreter. IncPy then automatically caches the results of long-running pure method calls to disk, manages dependencies between code and on-disk data, and later reuses results, rather than re-executing those methods. Furthermore, this approach also allows developers to customize the execution by inserting annotations, which can force IncPy to always or never cache particular methods. Our framework is similar in this sense because it also provides annotations to developers aggregate domain-specific knowledge.

Another approach that deals with the same problem is CacheOptimizer [2], which is based on two analysis parts. First, it performs a static code analysis to identify possible caching spots in database queries. Then, CacheOptimizer monitors readable weblogs and creates mappings between current workload and database access to decide which and when database access is cacheable. Although this approach addresses method caching opportunities, it is focused on database-centric web applications; thus, only database-related methods are supported. Our approach share commonalities with CacheOptimizer; however, we focus on general application methods while searching for cacheable options.

Baeza-Yates et al. [12] addressed the identification of cacheable content in a different way, by filtering infrequent queries of web search engines, which cause a reduction in hit ratio because caching them often does not lead to hits. Therefore, this approach can prevent infrequent queries from taking space of more frequent queries in the cache. The proposed cache monitors stateless and stateful information of query executions and has two fully-dynamic parts. The first part is an admission controlled cache that only admits queries that the admission policy classifies as future cache hits. All queries that the admission policy rejects are admitted to the second part of the cache, an uncontrolled cache. Both caches implement a regular cache policy, more specifically, LRU. The uncontrolled cache can, therefore, manage queries that are infrequent but appear in short bursts, considering that the admission policy will reject queries that it concludes to be infrequent. Thus, the uncontrolled cache can handle cases in which infrequent queries may be asked again by the same user or within a short period. It guarantees that fewer infrequent queries enter the controlled cache, which is expected to handle temporal locality better.

Also focusing on filtering content, TinyLFU [28] uses an approximate LFU structure, which maintains a representation of the access frequency of recently accessed contents, to boost the admission effectiveness of caches. TinyLFU acts reactively when the cache is full and decides whether it is worthwhile admitting content, considering the cost of an eviction and the usefulness of the new content. This approach is currently available to developers as a replacement policy of the Caffeine caching framework.

Sajeev and Sebastian [29] proposed a semi-intelligent admission technique using the multinomial logistic regression (MLR) classifier. They used previously collected traces to build an MLR model, which can classify the content worthiness class. Such class is achieved by computing six different parameters, which refers to the traffic and the content properties. Then, at runtime, every incoming content to the cache has its worthiness class computed or updated, and it is used in an admission control mechanism, based on thresholds, to decide whether the content should be admitted.

Different from programmatic solutions to application-level caching implementation, such as traditional caching libraries and frameworks, our proposed caching approach does not require any additional implementation, detaching caching concerns from the application. Furthermore, our framework can automatically capture all the application-specific information needed to achieve its objectives (i.e. select and cache cacheable content), as opposed to other solutions [1, 14], which demand input and configuration from developers. Despite not being required, our framework also allows developers to provide additional knowledge by using a declarative approach, which can improve the solution.

In addition to the traditionally explored access history and cache-related statistics in existing admission solutions [12, 29, 28], such as frequency and recency, our approach also considers caching metadata retrieved from the application during its execution, such as cost to retrieve, user sessions, cache size and data size. Such metadata are in fact information that developers use while designing and implementing application-level caching, and thus enrich the application model with valuable application-specific information regarding the applicability of caching. Our results provide evidence of the value of this kind of information.

Apart from exploring new kinds of metadata, our approach also differs from these admission solutions in the granularity of cached content. We address complex logic and personalized content, which are produced and handled by method calls of applications, as opposed to whole web pages or database queries. Moreover, we consider all method calls as cacheable options and do not focus on specific methods or types of web applications, as some approaches do [27, 24, 5, 2].