On a caching system with object sharing

TL;DR

This paper analyzes a shared caching system with multiple proxies, proposing a model to estimate cache-hit probabilities considering object sharing, and introduces methods to reduce eviction overhead, supported by numerical results from a prototype.

Contribution

It introduces a 'working-set' approximation for shared cache systems with object sharing, aiding in cache management and admission control.

Findings

The approximation accurately estimates cache-hit probabilities.

Object sharing among proxies affects cache performance.

Proposed methods reduce ripple evictions and request overhead.

Abstract

We consider a content-caching system thatis shared by a number of proxies. The cache could belocated in an edge-cloud datacenter and the proxies couldeach serve a large population of mobile end-users. Eachproxy operates its own LRU-list of a certain capacity inthe shared cache. The length of objects simultaneouslyappearing in plural LRU-lists is equally divided amongthem,i.e., object sharing among the LRUs. We provide a "working-set" approximation for this system to quicklyestimate the cache-hit probabilities under such objectsharing, which can be used to facilitate admission control.Also, a way to reduce ripple evictions,i.e.,setrequestoverhead, is suggested. We give numerical results for ourMemCacheD with Object Sharing (MCD-OS) prototype.

Tables

Table 1. TABLE I : Empirical hitting probabilities for a simulated cache under the IRM of size B = 1000 𝐵 1000 B=1000 memory units for unit-length objects ( ∀ n , ℓ n = 1 for-all 𝑛 subscript ℓ 𝑛 1 \forall n,~{}\ell_{n}=1 ) that is shared by three LRU-lists i = 0 , 1 , 2 𝑖 0 1 2 i=0,1,2 respectively with Zipf popularity parameters α 0 = .75 subscript 𝛼 0 .75 \alpha_{0}=.75 , α 1 = .5 subscript 𝛼 1 .5 \alpha_{1}=.5 , and α 2 = 1 subscript 𝛼 2 1 \alpha_{2}=1 . Simulation time was sufficiently long so that these hitting probabilities are obtained with high confidence.

$i$	$b_0$	$b_1$	$b_2$	$h_{i,1}$	$h_{i,10}$	$h_{i,100}$	$h_{i,1000}$
0	8	8	8	0.368	0.0758	0.0142	0.00226
0	8	8	64	0.407	0.0877	0.0158	0.00273
0	8	64	8	0.389	0.0823	0.0149	0.00271
0	8	64	64	0.422	0.0924	0.0167	0.0028
0	64	8	8	0.983	0.5138	0.1170	0.02303
0	64	8	64	0.989	0.5568	0.1325	0.02660
0	64	64	8	0.986	0.5387	0.1262	0.02366
0	64	64	64	0.992	0.5763	0.1445	0.02724
1	8	8	8	0.126	0.0412	0.0130	0.00423
1	8	8	64	0.136	0.0448	0.0138	0.00438
1	8	64	8	0.676	0.2991	0.1069	0.03422
1	8	64	64	0.699	0.3205	0.1131	0.03574
1	64	8	8	0.136	0.0438	0.0136	0.00425
1	64	8	64	0.143	0.0476	0.0146	0.00458
1	64	64	8	0.699	0.3159	0.1129	0.03639
1	64	64	64	0.726	0.3318	0.1205	0.03916
2	8	8	8	0.708	0.1142	0.0121	0.00116
2	8	8	64	1.000	0.7560	0.1292	0.01411
2	8	64	8	0.745	0.1281	0.0130	0.00146
2	8	64	64	1.000	0.7882	0.1419	0.01628
2	64	8	8	0.771	0.1383	0.0146	0.00168
2	64	8	64	1.000	0.7968	0.1419	0.01435
2	64	64	8	0.793	0.1502	0.0147	0.00153
2	64	64	64	1.000	0.8196	0.1597	0.01416

Table 2. TABLE II : Hitting probabilities numerically approximated instead using mean object lengths ( 5 ), solving ( 8 ) and substituting into ( 3 ), for the shared cache of Table I .

$i$	$b_0$	$b_1$	$b_2$	$h_{i,1}$	$h_{i,10}$	$h_{i,100}$	$h_{i,1000}$
0	8	8	8	0.365	0.0776	0.0143	0.00255
0	8	8	64	0.401	0.0872	0.0161	0.00288
0	8	64	8	0.386	0.0832	0.0153	0.00274
0	8	64	64	0.421	0.0926	0.0171	0.00307
0	64	8	8	0.984	0.5213	0.1228	0.02302
0	64	8	64	0.990	0.5622	0.1366	0.02579
0	64	64	8	0.988	0.5455	0.1308	0.02463
0	64	64	64	0.993	0.5846	0.1446	0.02740
1	8	8	8	0.126	0.0416	0.0133	0.00424
1	8	8	64	0.134	0.0446	0.0143	0.00455
1	8	64	8	0.678	0.3011	0.1071	0.03519
1	8	64	64	0.704	0.3197	0.1147	0.03779
1	64	8	8	0.133	0.0442	0.0142	0.00451
1	64	8	64	0.142	0.0472	0.0152	0.00482
1	64	64	8	0.701	0.3171	0.1136	0.03742
1	64	64	64	0.725	0.3353	0.1212	0.04002
2	8	8	8	0.694	0.1116	0.0118	0.00118
2	8	8	64	1.000	0.7556	0.1314	0.01399
2	8	64	8	0.734	0.1242	0.0132	0.00133
2	8	64	64	1.000	0.7861	0.1429	0.01530
2	64	8	8	0.756	0.1314	0.0140	0.00141
2	64	8	64	1.000	0.7995	0.1484	0.01594
2	64	64	8	0.787	0.1434	0.0154	0.00155
2	64	64	64	1.000	0.8249	0.1599	0.01727

Table 3. TABLE III : Hitting probabilities of LRUs i 𝑖 i when caches are not shared for parameters of system of Table I .

$i$	$b_0$	$b_1$	$b_2$	$h_{i,1}$	$h_{i,10}$	$h_{i,100}$	$h_{i,1000}$
0	64	64	8	0.9800	0.5084	0.11760	0.02259
1	64	64	8	0.6683	0.2944	0.10437	0.03503
2	64	64	8	0.7005	0.1123	0.01176	0.00113

Table 4. TABLE IV : Summary of MCD-OS behavior in response to set/get requests from a proxy.

proxy i issues get(k); hits in LRU i
•  promote item with key k to the head of LRU i
proxy i issues get(k); misses in LRU i but hits in cache
•  insert the item with key k into the head of LRU i
•  update the status of all other LRUs sharing this item (deflation)
proxy i issues get(k); misses in both LRU i and cache
•  return cache miss to client
// client is expected to fetch the item from database and issue set(k, v)
proxy i issues set(k, v); key k doesn’t exist in cache
•  package the key-value pair (k,v) into an item, store in cache
•  set virtual length of the item to its actual length
•  insert the item to head of LRU i
proxy i issues set(k, v); key k already exists in cache
•  update the item with key k to reflect the new value v
•  promote the item to head of LRU i
•  update the status of all other LRUs sharing this item (may involve a combination of inflation and deflation)

Table 5. TABLE V : Means and standard deviations of set request execution times under MCD-OS and MCD.

cache	mean	std dev
MCD	412 $\mu$s	111 $\mu$s
MCD-OS	474 $\mu$s	127 $\mu$ s

Equations

$$\mathcal{P}(n)$$

$${\ell }_n/|\mathcal{P}(n)|\le {\ell }_n,$$

$$\forall i{b}_i=\sum _{k=1}^N{h}_{i,k}{\ell }_k$$

$$\forall i,k{h}_{i,k}=1-\text{mbox}{e}^{-{\lambda }_{i,k}{t}_i}$$

$$\forall i,b_i$$

$$L_{i,k}^{(1)}$$

$$\mathbb{E}\frac{1}{1+{\sum }_{j\ne i}{Z}_{j,k}}$$

$$=1-\frac{1}{2}{h}_{3-j,k}.$$

$$0=b_i-\sum _{k=1}^N(1-\text{mbox}{e}^{-{\lambda }_{i,k}{t}_i})(1-\frac{1}{2}(1-\text{mbox}{e}^{-{\lambda }_{3-i,k}{t}_{3-i}})){\ell }_k;$$

$$\mathbb{P}\left(\sum _{j\ne i}{Y}_{j,k}\le x\right)\le \mathbb{P}\left(\sum _{j\ne i}{Z}_{j,k}\le x\right)$$

$$\mathbb{E}{\left(1+\sum _{j\ne i}{Y}_{j,k}\right)}^{-1}$$

$${\int }_{-\infty }^{\infty }g(x)\text{mbox}d{F}_i(x)={\int }_0^{1}g(F_i^{-1}(u))\text{mbox}du.$$

$$0=b_i-\sum _{k=1}^N{h}_{i,k}\mathbb{E}\frac{1}{1+{\sum }_{j\ne i}{Z}_{j,k}}{\ell }_k=:\frac{\partial u_i}{\partial t_i}=:{\partial }_i{u}_i$$

$$\forall i{b}_i<\frac{1}{J}\sum _{k=1}^N{\ell }_k,$$

$$\{t_j{\}}_{j=1}^J\in \prod _{j=1}^J[s_j,S_j]=:\mathcal{S}$$

$$\underset{t_i\to 0}{\lim }{\partial }_i{u}_i(t_i,{\underline{t}}_{-i})$$

$$\underset{t_i\to \infty }{\lim }{\partial }_i{u}_i(t_i,{\underline{t}}_{-i})$$

$$\le b_i-\frac{1}{J}\sum _{k=1}^N{\ell }_k<0,\text{mbox}by(\text{ref}{b}_i-bound).$$

$$\forall i,n,h_{i,n}\ge h_{i,n}^{\ast }$$

$$\sum _{i=1}^J{b}_i$$

$$\sum _{i=1}^J{b}_i^{\ast }$$

$$b_{J+1}^{\ast }$$

$$L_{i,k}^{(1)}$$

$$\ge$$

Full text

I Introduction

As the public cloud-computing marketplace rapidly expands and diversifies its services and associated pricing rules, the edge-cloud marketplace is still developing. Comparable edge-cloud services most likely will be much more expensive than those of the public (“remote”) cloud. In particular, content-caching services preferably locate at the edge to reduce networking costs and delays. One way to reduce their costs is to have different caching proxies (as, e.g., [18]) share objects stored in common cache memory.

We herein consider $J$ proxies that each service a large pool of users/processes making requests for content from a database with $N$ data-objects via a cache of size $B\ll N$ memory units, e.g., caching as part of a Content Distribution Network (CDN). Each proxy typically operates under a Least Recently Used (LRU) caching policy wherein the most recently queried for data-objects are cached. The $J$ proxies share both cache memory and possibly also the upload network-bandwidth to their users. Note that for caching of encrypted data (e.g., owing to copyright protections), a layered encryption strategy (as in block chains, legers) could be used to first encrypt to the network edge and then encrypt to the individual (authorized) users.

In this paper, we consider a caching system where the noncooperative proxies each pay for an allocation of cache memory (and possibly network I/O as well), thus preventing starvation of any proxy. Objects may be shared among different LRU-lists (or just “LRUs”, each corresponding to a proxy) as [16]. That is, the cost of storing a common object in the LRUs is shared among the proxies. Also, an LRU-list miss but physical cache hit is accompanied by a delay corresponding to a physical cache miss. This said, a proxy may make inferences regarding the LRU-lists of others by comparing the cache hits they experience to what they would be without object sharing. Mock queries may change some near-future LRU-list misses to hits (particularly for content not in the physical cache), but will come at the cost of both memory and network I/O resources (possibly causing some near-future cache misses that would have been hits). So, the free-riding behavior described in [16] is disincentivized.

Summary Contributions: We give an accurate working-set approximation for the cache-hit probabilities of the caching-with-object-sharing system of [16]. We implement this system in Memcached in part to practically ascertain the object sharing’s cache-eviction “ripple effect.” We also study the ripple-eviction problem and describe an approach to overbooking the caches that mitigates it.

This paper is organized as follows. Related prior work is discussed in Section II. In Section III, an approach to cache memory management is presented wherein a cached object’s length is shared among multiple LRU-lists. In Section IV, we propose an approach to approximating hitting times for such a system of shared cache memory under the Independent Reference Model (IRM) model. Numerical results are given in Section V. In Section VI, we described an implementation of MemCacheD with Object Sharing (MCD-OS) and give additional numerical results. Finally, we conclude with a summary and discussion of future work in Section VII.

II Related prior work

There is substantial prior work on cache sharing, including at the network edge in support of mobile end-users, e.g., [9, 20, 15]. At one extreme, the queries of the proxies are aggregated and one LRU cache is maintained for all of them using the entire cache memory. At another extreme, the cache memory is statically partitioned among the proxies (without object sharing). For example, [4] describes how cache memory can be partitioned according to a game wherein different proxy utilities increase with cache-hit probability. In our object-sharing problem formulation (involving non-cooperative users of a for-profit caching service), cache memory is not statically partitioned, but there is “virtual” cache memory allocated per user each of which is used for a LRU-list of potentially shared data objects.

For a system with a single LRU (LRU-list) in the cache, a lower priority (paying less) proxy could have a different tail (least recently used object) pointer corresponding to lower amount of allocated memory, but different proxies would then compete for “hot” (higher ranked) objects stored in the cache. To reduce such competition, an interesting system of [6] also has a single LRU maintained in the cache but with highest priority (paying most) proxies having access to the entire cache while lower priority proxies having a head (most recently used object) pointer corresponding to a lower amount of allocated memory.

Now consider a scenario where the clients of different proxies may query for (e.g., via a get request in Memcached) the same object. In [16], proxies are assigned a share of cached content based on their demand. Individual data objects are shared among different proxy caches that store them, each according to the LRU policy, i.e., a share of their length is attributed to each proxy’s cache (LRU-list). In [16], the cache blocks some requests selected at random to deter a proxy from “cheating” by issuing mock requests for specific content primarily of interest only to its users in order to keep it cached (hot), while leveraging cached content apportioned to other proxies, i.e., more generally popular content, recall the discussion of Section 1.

III Object-sharing in cache memory

Suppose cache memory is “virtually” allocated so that proxy $i\in\{1,2,...,J\}$ effectively receives $b_{i}\leq B$ amount of memory. Each partition is managed simply by a LRU linked-list of pointers (“LRU-list” or just “LRU” in the following) to objects stored in (physical) cache memory collectively for all the proxies.

Let $\mathcal{P}(n)\subset[J]$ be the set of proxies for which object $n$ currently appears in their LRU-list, where $\mathcal{P}(n)=\emptyset$ if and only if object $n$ is not physically cached. Note that $\mathcal{P}(n)$ is not disclosed to the proxies, i.e., the proxies cannot with certainty tell whether objects not in their LRU-list are in the cache.

Upon request by proxy $i$ for object $n$ of length $\ell_{n}$, object $n$ will be placed at the head of $i$’s LRU-list and all other objects in LRU-list $i$ are demoted in rank.

If the request for object $n$ was a hit on LRU-list $i$, then nothing further is done.

If it was a miss on LRU-list $i$, then

• •

if the object is not stored in the physical cache then it is fetched from the database, stored in the cache and forwarded to proxy $i$;

• •

otherwise, the object is produced for proxy $i$ after an equivalent delay.

Furthermore, add $i$ to $\mathcal{P}(n)$ (as in [16]), i.e.,

[TABLE]

then add the length $\ell_{n}/|\mathcal{P}(n)|$ to LRU-list $i$ and reduce the “share” of all other caches containing $n$ to $\ell_{n}/|\mathcal{P}(n)|$ (from $\ell_{n}/(|\mathcal{P}(n)|-1$)).

So, if the query for (get request of) object $n$ by proxy $i$ is a miss, its LRU-list length will be inflated and possibly exceed its allocation $b_{i}$; thus, LRU-list eviction of its tail (least recently used) object may be required. When an object $m$ is “LRU-list evicted” by any proxy, the apportionment of $\ell_{m}$ to other LRU-lists is increased (inflated), which may cause other objects to be LRU-list evicted by other proxies. A simple mechanism that the cache operator could use is to evict until no LRU-list exceeds its allocated memory is to iteratively:

identify the LRU-list $i$ with largest overflow (length minus allocation) 2. 2.

if this largest overflow is not positive then stop 3. 3.

evict $i$’s lowest-rank object 4. 4.

reassess the lengths of all caches 5. 5.

go to 1.

This is guaranteed to terminate after a finite number of iterations because in every iteration, one object is evicted from an LRU-list and there are obviously only ever a finite number of objects per LRU-list.

Figure 1 provides an illustration of such inflation for a shared cache serving 3 LRUs. Here, insertion of a new object causes evictions in all three LRUs.

As another example, consider a scenario where object $x$ is in LRU-list $j$ but not $i$ and object $y$ is in both but at the tail of $i$. Also, both caches are full. So, a query for $x$ by $i$ (LRU miss but cache hit) causes $i$ to evict $y$. Thus, from $j$’s point-of-view, $x$ deflates but $y$ inflates, so evictions from $j$ may or may not be required.

Also, a “set” request for an object simply updates an object in the cache which may cause it to inflate and, in turn, cause evictions. Though we do not consider set requests in this paper, our implementation does accommodate them, cf. Section VI.

Note that if during the eviction iterations, $\mathcal{P}(n)\rightarrow\emptyset$ for some object $n$, then $n$ may be removed from the physical cache (physically evicted) – cached objects $n$ in the physical cache that are not in any LRU-lists are flagged as such and have lowest priority (are first evicted if there is not sufficient room for any object that is/becomes a member of any LRU-list). Even under LRU-list eviction consensus, the physical cache may store an object if it has room to try to avoid having to fetch it again from the database in the future.

In summary, a single proxy $i$ can cause a new object $n$ to enter the cache ($\mathcal{P}(n)$ changes from $\emptyset$ to $\{i\}$) whose entire length $\ell_{n}$ is applied to its cache memory allocation $b_{i}$, but a consensus is required for an object $n$ to leave the cache ($\mathcal{P}(n)\rightarrow\emptyset$). So, the physical cache itself is not LRU. Also, as objects are requested, their apportionments to proxy LRU-lists may deflate and inflate over time.

Proposition III.1

For a fixed set of active proxies $i$, this object-sharing caching system will have a higher stationary object hit-rate per proxy compared to a not-shared system of LRU caches, where each proxy $i$’s LRU cache has the same amount of allocated memory ($b_{i}$) in both cases.

An elementary proof of this proposition is based on a simple coupling argument to show that for each proxy, the objects in the not-shared system’s cache are always a subset of what’s in the LRU-list of the shared system. This follows simply because the size of any object $n$ apportioned to the shared system

[TABLE]

i.e., not greater than its full size which is apportioned in the system without object sharing.

IV Approximating LRU-list hit probabilities under the IRM

IV-A Working-set approximations for shared-object caches under IRM

In this section, we propose an approach to computing the approximate hitting probabilities of the foregoing caching system following the Denning-Schwartz “working-set approximation” [5] for a not-shared cache under the IRM. [7, 8] nicely address the asymptotic accuracy of this approximation. Also see [3].

Let $\lambda_{i,k}$ be the mean request rate for object $k$, of length $\ell_{k}$, by proxy $i$. A simple generalization of the working-set approximation for variable-length objects is: if $\min_{i}b_{i}\gg\max_{k}\ell_{k}$ then

[TABLE]

where

[TABLE]

and $t_{i}$ are interpreted as (assumed common) mean eviction times of objects $k$ in LRU-list $i$, i.e., the time between when an object enters the cache and when it’s evicted from the cache.

For our shared caching system, only a fraction of an object $k$’s length $\ell_{k}$ will be attributed to a particular LRU-list $i$, depending on how $k$ is shared over (eviction) time $t_{i}$. For all $i,k$, let this attribution be $L_{i,k}\leq\ell_{k}$, i.e.,

[TABLE]

One may take

[TABLE]

where $Z_{j,k}$ are independent Bernoulli random variables such that $h_{j,k}={\mathbb{P}}(Z_{j,k}=1)=1-{\mathbb{P}}(Z_{j,k}=0)$. That is, under the assumption of independent LRU-lists, $L_{i,k}^{(1)}$ is the stationary mean attribution of the length of object $k$ to LRU-list $i$ given that $k$ is stored in LRU-list $i$. For example, for a system with just $J=2$ caches, i.e., $j\in\{1,2\}$,

[TABLE]

So, substituting (5) into (4) gives, for $i\in\{1,2\}$,

[TABLE]

a system with two nonlinear equations in two unknowns $t_{1},t_{2}$.

Empirically, we found that using (5) is a good estimate of when $J>2$, cf. Section V, but significantly under-estimates the object hitting probabilities, i.e., $L_{i,k}^{(1)}$ is too large, when $J=2$. To explain this, we argue that object sharing creates a kind of positive association between the LRU-list hit events, because hits in one cause the objects to effectively reduce in size in others, so that they remain in the LRU-lists longer (larger eviction times), thus increasing the hit probabilities in others.

To see why, consider the simple Prop. IV.1 below for Boolean random variables $Y_{j,k}$ indicating the dependent events that object $k$ is stored in LRU-list $j$ in steady-state.

Proposition IV.1

For an arbitrary object index $k$, consider $J\geq 2$ nonnegative random variables $Y_{1,k},\ldots,Y_{J,k}$ and $J$ other random variables $Z_{1,k},\ldots,Z_{J,k}$ such that, for all $i$, $Z_{i,k}$ and $Y_{i,k}$ have the same distribution. If for any LRU-list $i\in\{1,2,\ldots,J\}$ we have

[TABLE]

then

[TABLE]

Proof: Let $F_{1},F_{2}$ respectively be the CDFs of $\sum_{j\not=i}Y_{j,k}$. So by hypothesis, $F_{1}(x)\leq F_{2}(x)$ for all $x\in{\mathbb{R}}$. Let $F_{i}^{-1}(u):=\inf\{x\in{\mathbb{R}}:\,F_{i}(x)>u\}$, $i=1,2$. By change of variables in Lebesgue-Stieltjes integrals, we have

[TABLE]

Since $F_{1}\leq F_{2}$ we have $F_{1}^{-1}\geq F_{2}^{-1}$ and so $g(F_{1}^{-1}(u))\leq g(F_{2}^{-1}(u))$ for all $0<u<1$.

Finally, take $g(x)=1/(1+x)$. ∎

Note that, for our purposes herein, the random variables $Z_{j,k}$ are independent.

Also note that according to (6), $\sum_{j\not=i}Y_{j}$ tends to be larger than $\sum_{j\not=i}Z_{j}$, similar to positive associations or positive correlations properties among random variables $Y_{i}\geq 0$ [12, 10, 19].

Substituting (5) into (4) gives, for $i\in\{1,2,\ldots,J\}$,

[TABLE]

Under (3) and ${\mathbb{E}}Z_{j,k}=h_{j,k}$ for independent Boolean $Z_{j,k}$, equations (8) are a set of $J$ equations in $J$ unknowns $\{t_{i}\}_{i=1}^{J}$.

Note that for all the above definitions, $\forall i,k,~{}L_{i,k}\leq\ell_{k}$, so one expects corresponding hit cache probabilities to be larger than without object-sharing; recall Prop. III.1.

IV-B *Existence and uniqueness of solution to

the working-set approximation (8)*

A basic assumption is that,

[TABLE]

i.e., no LRU-list is large enough to hold all of the objects even if the objects were fully shared.

Proposition IV.2

If (9) holds then there are real numbers $s_{j}\geq 0,S_{j}<\infty$, such that $s_{j}<S_{j}$ and there exists a unique solution $\{t_{i}\}_{i=1}^{J}\in\prod_{i=1}^{J}[s_{i},S_{i}]$ to (8).

Proof: Consider the quantities $u_{i}$ as utilities of a noncooperative $J$-player game with strategies

[TABLE]

where $0\leq s_{j}<S_{j}<\infty$. First note that each $u_{i}$ of (8) is continuously differentiable on $\mathcal{S}$.

For a $J$-dimensional vector $\underline{t}=(t_{1},\ldots,t_{J})\in\mathcal{S}$ let $\underline{t}_{-i}$ be the $(J-1)$-vector obtained by eliminating the entry $t_{i}$. Since the strategy-space $\mathcal{S}$ is compact and the utility functions $u_{i}(\underline{t})$ are strictly concave in $t_{i}$ (since $\partial_{i}^{2}u_{i}<0$) a Nash equilibrium exists [1]. Alternatively, we can use Brouwer’s theorem [2] to establish existence of the Nash equilibrium.

Generally, a Nash equilibrium may occur on the boundary of the strategy-space. However, note here that for an arbitrary $\underline{t}_{-i}$,

[TABLE]

Because of this and the strict concavity of $u_{i}$ in $t_{i}$, if all $S_{j}$ are sufficiently large and $s_{j}\geq 0$ sufficiently small, then all $\partial_{i}u_{i}(\underline{t})$ are unimodal in $t_{i}$ for all $\underline{t}_{-i}$ such that $\underline{t}\in\mathcal{S}$. As a result, the Nash equilibria are all interior to $\mathcal{S}$ so that the first-order necessary conditions for $u_{i}$-optimality must all hold, i.e., (8) are satisfied.

By such unimodality and because strict concavity implies $\partial_{i}^{2}u_{i}\not=0$, uniqueness of the solution follows. ∎

Note that the diagonal-dominance conditions implying negative definiteness of the Jacobian of the gradient map, which would imply uniqueness of the solution $\{t_{i}\}_{i=1}^{J}$ to (8) [17, 14], do not hold here.

IV-C Discussion: overbooking with shared objects

Consider a caching system as described above with LRU-lists but without object sharing, i.e., the full length of an object is charged to each LRU-list in which it resides. In this case, from the proxies’ point-of-view, the system is just as static cache partitioning as mentioned in Section II. Suppose LRU/proxy $i$ is paying to experience the cache-hit probabilities it would get if cache memory amount $b_{i}^{*}$ was dedicated to it without object sharing, i.e., $b_{i}^{*}$ is prescribed in the Service Level Agreement (SLA). Consider a virtual cache memory allocation $b_{i}$ given by (4) and (5) (accurate for $J>3$ LRUs, cf. Section V). Specifically, let $h_{i,n}$ be the cache hitting probability of object $n$ under object sharing (so depends on $b_{i}$ - recall (2)) and $h_{i,n}^{*}$ be that without object sharing (so depends on $b_{i}^{*}$); and define minimal $b_{i}$ such that

[TABLE]

Object sharing with $J$ LRUs operates so that

[TABLE]

which allows for the possibility of overbooking, i.e.,

[TABLE]

For purposes of admission control, before the degree of object-sharing of a new LRU $J+1$ can be assessed, the cache operator can conservatively admit a new proxy $J+1$ if

[TABLE]

where the cloud operator estimates the “virtual” cache allocation $b_{i}$ for existing proxies $i\in\{1,2,...,J\}$. Once admitted, the object popularities $\lambda_{i,n}$ can be estimated and fed into our working-set approximation to compute cache-hit probabilities under object-sharing toward determining the proper virtual allocation $b_{i}$111Note that virtual allocations may also need to be recomputed when LRUs “depart” the cache.. Alternatively, the object cache-hit probabilities can be directly estimated by simply trial reducing virtual allocation $b_{J+1}$ starting from $b_{J+1}^{*}$. Or, LRU $J+1$ can be less conservatively admitted based on a virtual allocation correponding to some estimated object popularities based on those of existing LRUs $1,...,J$.

IV-D Discussion: Reducing Ripple Evictions (RRE)

Obviously, if two LRUs $i\not=j$ have very similar demand, then they will tend to have many of the same objects cached, so will tend to have larger ripple-eviction effects, recall Figure 1 and cf. Section VI-C. If the same objects in different LRUs are being evicted at approximately the same time, then a policy of delayed batch evictions may be effective at RRE.

Consider an allocation $\hat{b}_{i}$ to proxy $i$ satisfying $b_{i}\leq\hat{b}_{i}<b_{i}^{*}.$ Another approach is to give back $\sum_{i}\hat{b}_{i}-b_{i}$ in memory savings in order to reduce ripple evictions. Let a primary eviction on an LRU be one that is caused when a cache miss occurs on it. Primary evictions occur when LRU $i$ exceeds $b_{i}$, but ripple evictions occur only when LRU $i$ exceeds $\hat{b}_{i}$. So, LRU $i$ may at times exceed $b_{i}$ (but never exceeds $\hat{b}_{i}$). Note that under object sharing, some LRUs $i$ may shrink in size when a miss occurs for LRU $j\not=i$ involving an object in LRU $i$ (i.e., an LRU miss that’s a physical cache hit); once an LRU $i$ becomes less than $b_{i}$ it remains so until a future ripple eviction.

V Numerical results on cache

memory sharing

We ran a number of experiments to test our working-set approximation of cache-hit probabilities for the object-sharing cache. To approximate, we solved (8) using the Newton-Raphson algorithm; this was simplified by the concavity properties and uniqueness of solution discussed in the proof of Prop. IV.2.

Typical results for a cache shared by three or more LRU-lists are shown in Tables I and II (for $J=3$ LRU-lists). Here we see that the approximation (5) is reasonably accurate.

But for the $J=2$ LRU system, the approximation (5) tends to underestimate cache-hit probabilities by $\sim 30\%$. One can use Jensen’s inequality on (5) to get222By the same argument, Proposition IV.2 is also true under (14) or (15), the latter with $s_{i}>0$ for all $i$.:

[TABLE]

Empirically, we found that using $L_{i,k}^{*}$ for the working-set approximation gives approximate hitting probabilities only marginally larger than (5). But, empirically, we found that using $L_{i,k}^{(2)}$ tends to overestimate [11]. That is, one can use (5) (15) to find upper and lower bounds for the $J=2$ cache case.

Finally, we note from Table III the lower cache-hit probabilities for a typical instance of the set of parameters of the caching system of Table I, again consistent with the statement of Prop. III.1. The differences range from marginal to over 10% in the case of the LRU $2$ with the smaller memory allocation ($b_{2}=8$).

VI MemCacheD with Object Sharing (MCD-OS)

VI-A Background on Memcached

Memcached (MCD) is a popular distributed in-memory cache [13] that offers a set/get key-value API (it offers some additional functions such as update which is a special case of set so we ignore them). Placement/routing of requests to servers within a cluster is done via a consistent hashing function that clients apply to keys. If a get request is a hit, the server holding the requested key-value pair responds with the value. If the get is a miss, then the client must fetch the item from a (remote) database and issue a set command to the cache. The set command will add the object if it is not already in the cache, otherwise it will update its value. To guarantee O(1) access time, MCD maintains a hash table on the server side linking all objects in cache, where an object is indexed by the hash value of its key.

The basic unit of storage in MCD is an item which stores a key-value pair and some meta-data such as a time-to-live (TTL) value. To overcome internal memory fragmentation, MCD divides memory into multiple slabs each of which contains items within a range of sizes. Slabs are 1MB large by default. A group of slabs containing items within the same size range is called a slabclass. Instead of using the vanilla LRU, MCD uses type of segmented LRU (S-LRU) that is known to approximate LRU well while posing lower computational needs (and processing delay) when servicing hits (which is the common case in a well-provisioned cache). In MCD’s S-LRU, items are separated into three sub-lists called HOT, WARM, and COLD. Newly created items always begin in HOT which is an LRU-based list. An item at the tail of HOT is moved onto WARM only if it has a relatively long TTL and have been accessed at least twice (two or more accesses is taken as indicative of relatively high popularity). WARM holds popular and long-lived items and is operated as a first-in first-out (FIFO) list. Finally, COLD holds relatively unpopular items and is operated as an LRU list.

VI-B Our implementation

We implement an MCD with object sharing, MCD-OS, by making modifications to Memcached v. 1.5.16. We make no changes to the client side of MCD. Our prototype is available here [11]. In particular, we retain MCD’s consistent hashing functionality for client-driven content placement/routing in clustered settings as is. We make several changes to the server side of MCD. Requests coming from each proxy are handled by a pool of MCD-OS threads dedicated to that proxy. We retain the slabclass functionality for its fragmentation-related benefits and hash table for quick object access. An item’s slabclass continues to be determined by its actual (and not inflated/deflated) size. However, we remove per-slabclass LRU lists and instead implement a single LRU per proxy. Given our specific interest in the LRU replacement policy, we set up MCD-OS in our evaluation such that: (i) flat LRU as opposed to S-LRU is used and (ii) there is only one slabclass. Implementing MCD-OS for S-LRU with multiple slabclasses is part of our ongoing work.

Note that on an LRU miss, MCD-OS will require the proxy to fetch the object from a remote database and issue a set command to store it in cache followed by adding the item to the front of this proxy’s LRU-list. Therefore, there is no need for MCD-OS to add an artificial delay in response to an LRU miss that is a physical cache hit.

In Table IV, we summarize different types of behavior offered by MCD-OS in response to set/get requests from a proxy. We present the key functionalities implemented in MCD-OS to achieve this behavior as a list of functions below. We selectively list new logic added by us and omit related functionality that MCD already implements. In the Appendix, we provide detailed pseudocode for these functions.

inflate**:** This new function is invoked when a shared item needs to be inflated. This happens upon the eviction of that item from one of the proxy LRUs or if the virtual length of the item increases after a set operation.

deflate**:** This new function is invoked when a shared item needs to be deflated. This happens upon the insertion into a proxy LRU of an item that is shared with one or more other proxies, or if the virtual length of the item decreases after a set operation.

insert**:** This is analogous to the native MCD function item_link that inserts an item into the appropriate LRU-list. It is used for item insertion and replacement. We modify it to also invoke the functions inflate or deflate corresponding to an increase or a decrease in the virtual length of the inserted item.

evict**:** This is analogous to the native MCD function item_unlink that evicts an item from its LRU-list. We modify it to also invoke the function inflate after item eviction to update virtual lengths of copies of the evicted item that still resides in some other proxies’ LRU-lists.

process_command**:** This is a native MCD function that parses client requests and implements get and set logic. We enhance it to additionally implement object sharing.

VI-C Overhead of object sharing for MCD-OS

Object sharing introduces additional overhead for set commands associated with a ripple of evictions among the LRUs owing to item size deflation/inflation. In the following, we compare the overhead of set commands (after a cache miss) for MCD-OS and MCD, the latter with the same collective get commands but a single LRU cache of the same collective size ($\sum_{i}b_{i}$).

For our experiments, we used $J=9$ proxies with $N=10^{6}$ items, where each item was 100kB. The total cache memory was 3 GB. In a typical experiment, we considered very different proxies $i\in[J]$ with Zipf parameter $0.5+0.5(i-1)$ and memory allocations: $b=$100 MB for proxies 1,2,3; $b=$200 MB for proxies 4,5,6; and $b=$700 MB for proxies 7,8,9. The number of get commands issued in each experiment was $3\times 10^{6}$ after the cold misses have abated. The histogram of the number of evictions per set request for MCD-OS is given in Figure 2. As shown, in a small number of cases, the size of this “eviction ripple” can be as large as 9. However, overall only 16% of the set requests experienced more than one eviction (i.e., an overhead beyond what an eviction in MCD would experience).

In Figure 3, the CDFs of the set execution times are plotted under both MCD and MCD-OS. Note that, though there is a single eviction per set under MCD, there is some variability when updating the LRU. See Table V.

Other experiments showed that when all the proxies are very similar, the additional set overhead was reduced, even negligible. Also, a get under MCD-OS would obviously require additional overhead to look-up which LRU (based on proxy identifier) is requested, but we found it to be negligible.

VII Summary and Future Work

In this paper, we considered object sharing by LRU caches. Such sharing will reduce the cost of operation at a given level of performance (cache-hit probabilities) or improve performance for given budgets. We proposed an extension of the classical working-set approximation of cache-hit probabilities to this shared-object setting, and evaluated its performance both numerically and based on experiments with a Memcached prototype (MemDacheD-OS or MCD-OS) [11]. This approximation may be used for admission control to help determine virtualized memory resources to be allocated under object sharing. We also numerically evaluated the set overhead of object sharing.

We have also implemented MCD-OS for commonly used Segmented-LRU (S-LRU) with multiple slabclasses, where S-LRU is designed to reduce memory overhead for popular (hot) objects. Cache-hit probabilities do not change significantly ($\sim 2-3\%$ difference) under S-LRU under object sharing.

In ongoing work, we are evaluating the method of Section IV-D to reduce the overhead of ripple evictions. We are also evaluating MCD-OS with variable-length objects which are allocated in different slabs.