EC-Cache Load-balanced, Low-latency Cluster Caching with ... · EC-Cache: Load-balanced,...

EC-Cache: Load-balanced, Low-latency Cluster Caching with

Online Erasure Coding

Joint work with

Mosharaf Chowdhury, Jack Kosaian (U Michigan) Ion Stoica, Kannan Ramchandran (UC Berkeley)

Rashmi'Vinayak'

UC#Berkeley

Caching'for'data4intensive'clusters

• Data.intensive#clusters#rely#on#distributed, in-memory#caching#for#high#performance#

. Reading#from#memory#orders#of#magnitude#faster#than#from#disk/ssd#

. Example:##Alluxio#(formerly#Tachyon†)

†Li#et#al.#SOCC#2014# 2

Imbalances'prevalent'in'clusters'

Sources#of#imbalance:#

• Skew#in#object#popularity#

• Background#network#imbalance#

• Failures/unavailabiliRes

• Failures/unavailabilites

Small#fracRon#of#objects#highly#popular#. Zipf.like#distribuRon##. Top#5%#of#objects#7x#more#popular#than#boWom#75%†#

(Facebook#and#MicrosoY#producRon#cluster#traces)

†Ananthanarayanan#et#al.#NSDI#2012#

Some#parts#of#the#network#more#congested#than#others#. RaRo#of#maximum#to#average#uRlizaRon#more#than#4.5x#

with#>#50%#uRlizaRon##

(Facebook#data.analyRcs#cluster)

Some#parts#of#the#network#more#congested#than#others#. RaRo#of#maximum#to#average#uRlizaRon#more#than#4.5x#

with#>#50%#uRlizaRon##

(Facebook#data.analyRcs#cluster)

†#Chowdhury#et#al.#SIGCOMM#2013#

. Similar#observaRons#from#other#producRon#clusters†

• Background#load#imbalance#

Norm#rather#than#the#excepRon#. median#>#50#machine#unavailability#events#every#day#in#a#

cluster#of#several#thousand#servers†#

(Facebook#data#analyRcs#cluster)

†Rashmi#et#al.#HotStorage#2013 6

➡ Adverse#effects:#4 load#imbalance'

. high#read#latency

Imbalances'prevalent'in'cluster'

➡ Adverse#effects:#4 load#imbalance'

. high#read#latency

Imbalances'prevalent'in'cluster'

Single#copy#in#memory#oYen#not#sufficient#to#get#good#performance

Popular'approach:'Selec?ve'Replica?on

• Uses#some#memory#overhead#to#cache#replicas#of#objects#based#on#their#popularity#. more#replicas#for#more#popular#objects

GET A GET B

…Server 1 Server 2 Server 3

GET A GET AGET B

1x 1x1x

GET A GET AGET B

1x 1x1x

• Used#in#data.intensive#clusters†#as#well#as#widely#used#in#key.value#stores#for#many#web.services#such#as#Facebook#Tao‡

†Ananthanarayanan#et#al.#NSDI#2011,##‡Bronson#et#al.#ATC!20138

Memory'Overhead

Read'performance''

&'Load'balance''

Memory'Overhead

Read'performance''

&'Load'balance''

Single'copy''

in'memory

Memory'Overhead

Read'performance''

&'Load'balance''

Single'copy''

in'memory

Selec?ve'

replica?on

Memory'Overhead

Read'performance''

&'Load'balance''

Single'copy''

in'memory

Selec?ve'

replica?on

EC4Cache

Memory'Overhead

Read'performance''

&'Load'balance''

Single'copy''

in'memory

Selec?ve'

replica?on

EC4Cache

“Erasure'Coding”

Quick'primer'on'erasure'coding

• Takes#in#k data units#and#creates#r##“parity” units

• Any$k#of#the#(k+r)#units#are#sufficient#to#decode#the#original#k#data#units

• k = 5 • r = 4

data units parity units

d1 d2 d3 d4 d5 p1 p2 p3 p4

• k = 5 • r = 4

d1 d2 d3 d4 d5 p1 p2 p3 p4

• k = 5 • r = 4

Decode

d1 d2 d3 d4 d5 p1 p2 p3 p4

d1 d2 d3 d4 d5

• k = 5 • r = 4

d1 d2 d3 d4 d5 p1 p2 p3 p4

• k = 5 • r = 4

d1 d2 d3 d4 d5 p1 p2 p3 p4

Decode

d1 d2 d3 d4 d5

EC4Cache'bird’s'eye'view:'Writes

Caching#servers

k#=#2Splitd2

• Object#split#into#k#data#units

Caching#servers

k#=#2#r#=#1

Encode

k#=#2Splitd2

• Encoded#to#generate#r#parity#units

Caching#servers

k#=#2#r#=#1

Encode

k#=#2Splitd2

p1d1 d2

• Encoded#to#generate#r#parity#units

• (k+r)#units#cached#on#disRnct#servers#chosen#uniformly#at#random Caching#servers

EC4Cache'bird’s'eye'view:'Reads

• Read#from#(k#+#Δ)#units#of#the#object#chosen#uniformly#at#random#

. “AddiRonal#reads”

• Use#the#first#k#units#that#arrive

… k#=#2#r#=#1

p1d1 d2

Caching#servers

… k#=#2#r#=#1

Δ#=#1#k#+#Δ#=#3

Read units

p1d1 d2

Caching#servers

… k#=#2#r#=#1

Δ#=#1#k#+#Δ#=#3

Read units

p1d1 d2

Caching#servers

… k#=#2#r#=#1

Δ#=#1#k#+#Δ#=#3

Read units

p1d1 d2

Caching#servers

… k#=#2#r#=#1

Δ#=#1#k#+#Δ#=#3

Read units

p1d1 d2

Caching#servers

… k#=#2#r#=#1

Decode

Δ#=#1#k#+#Δ#=#3

Read units

p1d1 d2

• Decode#the#data#units

Caching#servers

… k#=#2#r#=#1

Decode

Δ#=#1#k#+#Δ#=#3

Read units

p1d1 d2

Combine

• Decode#the#data#units

• Combine#the#decoded#units

Caching#servers

Erasure'coding:'How'does'it'help?

1. Finer'control'over'memory'overhead'

. SelecRve#replicaRon#allows#only#integer#control#

. Erasure#coding#allows#fracRonal#control#

. E.g.,#k#=#10#allows#control#in#of#mulRples#of#0.1

1. Finer'control'over'memory'overhead'

. SelecRve#replicaRon#allows#only#integer#control#

. Erasure#coding#allows#fracRonal#control#

. E.g.,#k#=#10#allows#control#in#of#mulRples#of#0.1

2. Object'spliRng'helps'in'load'balancing'

. Smaller#granularity#reads#help#to#smoothly#spread#load#

. Analysis#on#a#certain#simplified#model:Theorem 1 For the setting described above:

Var(LEC-Cache)

Var(LSelective Replication)=

Proof: Let w > 0 denote the popularity of each of thefiles. The random variable LSelective Replication is distributedas a Binomial random variable with F trials and successprobability 1

S , scaled by w. On the other hand, LEC-Cacheis distributed as a Binomial random variable with kF tri-als and success probability 1

S , scaled by wk . Thus we have

Var(LEC-Cache)

Var(LSelective Replication)=

(kF ) 1

�1� 1

� =1

thereby proving our claim. ⇤Intuitively, the splitting action of EC-Cache leads to

a smoother load distribution in comparison to selectivereplication. One can further extend Theorem 1 to accom-modate a skew in the popularity of the objects. Such anextension leads to an identical result on the ratio of thevariances. Additionally, the fact that each split of an ob-ject in EC-Cache is placed on a unique server furtherhelps in evenly distributing the load, leading to even bet-ter load balancing.

5.2 Impact on Latency

Next, we focus on how object splitting impacts read la-tencies. Under selective replication, a read request foran object is served by reading the object from a server.We first consider naive EC-Cache without any additionalreads. Under naive EC-Cache, a read request for an ob-ject is served by reading k of its splits in parallel fromk servers and performing a decoding operation. Let usalso assume that the time taken for decoding is negligi-ble compared to the time taken to read the splits.

Intuitively, one may expect that reading splits in paral-lel from different servers will reduce read latencies dueto the parallelism. While this reduction indeed occurs forthe average/median latencies, the tail latencies behave inan opposite manner due to the presence of stragglers –one slow split read delays the completion of the entireread request.

In order to obtain a better understanding of the afore-mentioned phenomenon, let us consider the followingsimplified model. Consider a parameter p 2 [0, 1] andassume that for any request, a server becomes a stragglerwith probability p, independent of all else. There are twoprimary contributing factors to the distributions of the la-tencies under selective replication and EC-Cache:

(a) Proportion of stragglers: Under selective replica-tion, the fraction of requests that hit stragglers is p. Onthe other hand, under EC-Cache, a read request for anobject will face a straggler if any of the k servers fromwhere splits are being read becomes a straggler. Hence,

a higher fraction�1� (1� p)k

�of read requests can hit

stragglers under naive EC-Cache.(b) Latency conditioned on absence/presence of strag-

glers: If a read request does not face stragglers, the timetaken for serving a read request is significantly smallerunder EC-Cache as compared to selective replication be-cause splits can be read in parallel. On the other hand, inthe presence of a straggler in the two scenarios, the timetaken for reading under EC-Cache is about as large asthat under selective replication.

Putting the aforementioned two factors together we getthat the relatively higher likelihood of a straggler underEC-Cache increases the number of read requests incur-ring a higher latency. The read requests that do not en-counter any straggler incur a lower latency as comparedto selective replication. These two factors explain the de-crease in the median and mean latencies, and the increasein the tail latencies.

In order to alleviate the impact on tail latencies, weuse additional reads and late binding in EC-Cache. Reed-Solomon codes have the property that any k of the collec-tion of all splits of an object suffice to decode the object.We exploit this property by reading more than k splitsin parallel, and using the k splits that are read first. It iswell known that such additional reads help in mitigatingthe straggler problem and alleviate the affect on tail la-tencies [36, 82].

6 Evaluation

We evaluated EC-Cache through a series of experimentson Amazon EC2 [1] clusters using synthetic workloadsand traces from Facebook production clusters. The high-lights of the evaluation results are:• For skewed popularity distributions, EC-Cache im-

proves load balancing over selective replication by3.3⇥ while using the same amount of memory. EC-Cache also decreases the median latency by 2.64⇥and the 99.9th percentile latency by 1.79⇥ (§6.2).

• For skewed popularity distributions and in the pres-ence of background load imbalance, EC-Cache de-creases the 99.9th percentile latency w.r.t. selectivereplication by 2.56⇥ while maintaining the samebenefits in median latency and load balancing as inthe case without background load imbalance (§6.3).

• For skewed popularity distributions and in the pres-ence of server failures, EC-Cache provides a gracefuldegradation as opposed to the significant degradationin tail latency faced by selective replication. Specif-ically, EC-Cache decreases the 99.9th percentile la-tency w.r.t. selective replication by 2.8⇥ (§6.4).

• EC-Cache’s improvements over selective replicationincrease as object sizes increase in production traces;

3. Object'spliRng'reduces'median'latency'but'hurts'tail'

latency'

. Read#parallelism#helps#reduce#median#latency#

. Straggler#effect#hurts#tail#latency#(if#no#addiRonal#reads)

3. Object'spliRng'reduces'median'latency'but'hurts'tail'

latency'

. Read#parallelism#helps#reduce#median#latency#

. Straggler#effect#hurts#tail#latency#(if#no#addiRonal#reads)

4. “Any'k'out'of'(k+r)”'property'helps'to'reduce'tail'latency'

. Read#from#(k#+#Δ)#and#use#the#first#k#that#arrive##

. Δ#=#1#oYen#sufficient#to#reign#in#tail#latency

Design'considera?ons

Storage#systems EC.Cache

• Space.efficient#fault#tolerance • Reduce#read#latency#

• Load#balance

1. Purpose'of'erasure'codes

2. Choice'of'erasure'code

†Rashmi#et#al.#SIGCOMM#2014,##Sathiamoorthy#et#al.#VLDB#2013,#Huang#et#al.#ATC!2012

• OpRmize#resource#usage#during#reconstrucRon#operaRons†#

• Some#codes#do#not#have###“any#k#out#of#(k+r)”#property

†Rashmi#et#al.#SIGCOMM#2014,##Sathiamoorthy#et#al.#VLDB#2013,#Huang#et#al.#ATC!2012

• No#reconstrucRon#operaRons#in#caching#layer;#data#persisted#in#underlying#storage#

• “Any#k#out#of#(k+r)”#property#helps#in#load#balancing#and#reducing#latency#when#reading#objects

• OpRmize#resource#usage#during#reconstrucRon#operaRons†#

• Some#codes#do#not#have###“any#k#out#of#(k+r)”#property

3. How'do'we'use'erasure'coding:'across'vs.'within'objects

• Some#systems#encode#across#objects#(e.g.,#HDFS.RAID);#some#within#(e.g.,#Ceph)#

• Does#not#affect#fault#tolerance#

• Need#to#encode#within#objects#. To#spread#load#across#both#data#&#parity#

• Encoding#across:#Very#high#BW#overhead#for#reading#object#using#pariRes†

• Some#systems#encode#across#objects#(e.g.,#HDFS.RAID);#some#within#(e.g.,#Ceph)#

• Does#not#affect#fault#tolerance#

†Rashmi#et#al.#SIGCOMM#2014,##HotStorage#2013 17

Implementa?on

• EC.Cache#on#top#of#Alluxio#(formerly#Tachyon)#

. Backend#caching#servers:#cache#data#—#unaware#of#erasure#coding##

. EC.Cache#client#library:#all#read/write#logic#handled

Implementa?on

• Reed.Solomon#code#

. Any#k#out#of#(k+r)#property

Implementa?on

• Reed.Solomon#code#

. Any#k#out#of#(k+r)#property

• Intel#ISA.L#hardware#acceleraRon#library##

. Fast#encoding#and#decoding

Evalua?on'set4up

• Amazon#EC2

• 25#backend#caching#servers#and#30#client#servers#

Evalua?on'set4up

• Amazon#EC2

• Object#popularity:#Zipf#distribuRon#with#high#skew

Evalua?on'set4up

• Amazon#EC2

• EC.Cache#uses#k#=#10,##Δ#=#1#

. BW#overhead#=#10%

Evalua?on'set4up

• Amazon#EC2

• EC.Cache#uses#k#=#10,##Δ#=#1#

. BW#overhead#=#10%

• Varying#object#sizes

Load'balancing

Servers Sorted by Load 0 50

100 150 200 250 300 350 400

Servers Sorted by Load

SelecRve#ReplicaRon EC.Cache

Load'balancing

100 150 200 250 300 350 400

• Percent#imbalance#metric:

e.g., 5.5⇥ at median for 100 MB objects with an up-ward trend (§6.5).

• EC-Cache outperforms selective replication across awide range of values of k, r, and � (§6.6).

6.1 Methodology

Cluster Unless otherwise specified, our experimentsuse 55 c4.8xlarge EC2 instances. 25 of these machinesact as the backend servers for EC-Cache, each with 8GB cache space, and 30 machines generate thousandsof read requests to EC-Cache. All machines were in thesame Amazon Virtual Private Cloud (VPC) with 10 Gbpsenhanced networking enabled; we observed around 4-5 Gbps bandwidth between machines in the VPC usingiperf.

As mentioned earlier, we implemented EC-Cache onAlluxio [56], which, in turn, used Amazon S3 [2] as itspersistence layer and runs on the 25 backend servers. Weused DFS-Perf [5] to generate the workload on the 30client machines.

Metrics Our primary metrics for comparison are la-tency in reading objects and load imbalance across thebackend servers.

Given a workload, we consider mean, median, andhigh-percentile latencies. We measure improvements inlatency as:

Latency Improvement =Latency w/ Compared Scheme

Latency w/ EC-Cache

If the value of this “latency improvement” is greater (orsmaller) than one, EC-Cache is better (or worse).

We measure load imbalance using the percent imbal-ance metric � defined as follows:

✓Lmax

� Lavg?

◆⇤ 100, (1)

where Lmax

is the load on the server which is maximallyloaded and Lavg? is the load on any server under an oraclescheme, where the total load is equally distributed amongall the servers without any overhead. � measures thepercentage of additional load on the maximally loadedserver as compared to the ideal average load. BecauseEC-Cache operates in the bandwidth-limited regime, theload on a server translates to the total amount of data readfrom that server. Lower values of � are better. Note thatthe percent imbalance metric takes into account the ad-ditional load introduced by EC-Cache due to additionalreads.

Setup We consider a Zipf distribution for the popular-ity of objects, which is common in many real-world ob-ject popularity distributions [20, 23, 56]. Specifically, weconsider the Zipf parameter to be 0.9 (that is, high skew).

Unless otherwise specified, we allow both selectivereplication and EC-Cache to use 15% memory overhead

238 286 43

99 93 141 22

Mean Median 95th 99th 99.9th

Selective Replication

EC-Cache

283 340

96 90 134 193

EC-Cache

Figure 8: Read latencies under skewed popularity of objects.

to handle the skew in the popularity of objects. Selec-tive replication uses all the allowed memory overheadfor handling popularity skew. Unless otherwise specified,EC-Cache uses k = 10 and � = 1. Thus, 10% of the al-lowed memory overhead is used to provide one parityto each object. The remaining 5% is used for handlingpopularity skew. Both schemes make use of the skew in-formation to decide how to allocate the allowed memoryamong different objects in an identical manner: the num-ber of replicas for an object under selective replicationand the number of additional parities for an object underEC-Cache are calculated so as to flatten out the popu-larity skew to the extent possible starting from the mostpopular object, until the memory budget is exhausted.

Moreover, both schemes use uniform random place-ment policy to evenly distribute objects (splits in case ofEC-Cache) across memory servers.

Unless otherwise specified, the size of each objectconsidered in these experiments is 40 MB. We presentresults for varying object sizes observed in the Facebooktrace in Section 6.5. In Section 6.6, we perform a sensi-tivity analysis with respect to all the above parameters.

Furthermore, we note that while the evaluations pre-sented here are for the setting of high skew in objectpopularity, EC-Cache outperforms selective replicationin scenarios with low skew in object popularity as well.Under high skew, EC-Cache offers significant benefitsin terms of load balancing and read latency. Under lowskew, while there is not much to improve in load balanc-ing, EC-Cache will still provide latency benefits.

6.2 Skew Resilience

We begin by evaluating the performance of EC-Cache inthe presence of skew in object popularity.

Latency Characteristics Figure 8 compares the mean,median, and tail latencies of EC-Cache and selectivereplication. We observe that EC-Cache improves medianand mean latencies by 2.64⇥ and 2.52⇥, respectively.EC-Cache outperforms selective replication at high per-

Load'balancing

100 150 200 250 300 350 400

λSR = 43.45% λEC = 13.14%

• Percent#imbalance#metric:

e.g., 5.5⇥ at median for 100 MB objects with an up-ward trend (§6.5).

• EC-Cache outperforms selective replication across awide range of values of k, r, and � (§6.6).

6.1 Methodology

Cluster Unless otherwise specified, our experimentsuse 55 c4.8xlarge EC2 instances. 25 of these machinesact as the backend servers for EC-Cache, each with 8GB cache space, and 30 machines generate thousandsof read requests to EC-Cache. All machines were in thesame Amazon Virtual Private Cloud (VPC) with 10 Gbpsenhanced networking enabled; we observed around 4-5 Gbps bandwidth between machines in the VPC usingiperf.

As mentioned earlier, we implemented EC-Cache onAlluxio [56], which, in turn, used Amazon S3 [2] as itspersistence layer and runs on the 25 backend servers. Weused DFS-Perf [5] to generate the workload on the 30client machines.

Metrics Our primary metrics for comparison are la-tency in reading objects and load imbalance across thebackend servers.

Given a workload, we consider mean, median, andhigh-percentile latencies. We measure improvements inlatency as:

Latency Improvement =Latency w/ Compared Scheme

Latency w/ EC-Cache

If the value of this “latency improvement” is greater (orsmaller) than one, EC-Cache is better (or worse).

We measure load imbalance using the percent imbal-ance metric � defined as follows:

✓Lmax

� Lavg?

◆⇤ 100, (1)

where Lmax

is the load on the server which is maximallyloaded and Lavg? is the load on any server under an oraclescheme, where the total load is equally distributed amongall the servers without any overhead. � measures thepercentage of additional load on the maximally loadedserver as compared to the ideal average load. BecauseEC-Cache operates in the bandwidth-limited regime, theload on a server translates to the total amount of data readfrom that server. Lower values of � are better. Note thatthe percent imbalance metric takes into account the ad-ditional load introduced by EC-Cache due to additionalreads.

Setup We consider a Zipf distribution for the popular-ity of objects, which is common in many real-world ob-ject popularity distributions [20, 23, 56]. Specifically, weconsider the Zipf parameter to be 0.9 (that is, high skew).

Unless otherwise specified, we allow both selectivereplication and EC-Cache to use 15% memory overhead

238 286 43

99 93 141 22

EC-Cache

283 340

96 90 134 193

EC-Cache

Figure 8: Read latencies under skewed popularity of objects.

to handle the skew in the popularity of objects. Selec-tive replication uses all the allowed memory overheadfor handling popularity skew. Unless otherwise specified,EC-Cache uses k = 10 and � = 1. Thus, 10% of the al-lowed memory overhead is used to provide one parityto each object. The remaining 5% is used for handlingpopularity skew. Both schemes make use of the skew in-formation to decide how to allocate the allowed memoryamong different objects in an identical manner: the num-ber of replicas for an object under selective replicationand the number of additional parities for an object underEC-Cache are calculated so as to flatten out the popu-larity skew to the extent possible starting from the mostpopular object, until the memory budget is exhausted.

Moreover, both schemes use uniform random place-ment policy to evenly distribute objects (splits in case ofEC-Cache) across memory servers.

Unless otherwise specified, the size of each objectconsidered in these experiments is 40 MB. We presentresults for varying object sizes observed in the Facebooktrace in Section 6.5. In Section 6.6, we perform a sensi-tivity analysis with respect to all the above parameters.

Furthermore, we note that while the evaluations pre-sented here are for the setting of high skew in objectpopularity, EC-Cache outperforms selective replicationin scenarios with low skew in object popularity as well.Under high skew, EC-Cache offers significant benefitsin terms of load balancing and read latency. Under lowskew, while there is not much to improve in load balanc-ing, EC-Cache will still provide latency benefits.

6.2 Skew Resilience

We begin by evaluating the performance of EC-Cache inthe presence of skew in object popularity.

Latency Characteristics Figure 8 compares the mean,median, and tail latencies of EC-Cache and selectivereplication. We observe that EC-Cache improves medianand mean latencies by 2.64⇥ and 2.52⇥, respectively.EC-Cache outperforms selective replication at high per-

>'3x'reduc?on'in'load'imbalance'metric20

Read'latency

283 340

134 193

0 200 400 600 800

1000 1200 1400

s) Selective Replication

EC-Cache

Read'latency

• Median:#2.64x#improvement#

• 99th#and#99.9th:#~1.75x#improvement

283 340

134 193

0 200 400 600 800

1000 1200 1400

s) Selective Replication

EC-Cache

Varying'object'sizes

5.5x improvement for 100MB

More'improvement'for'larger'object'sizes

10 30 50 70 90

Object Size (MB)

EC-Cache (Median) Selective Replication (Median)

Median#latency

10 30 50 70 90

Object Size (MB)

EC-Cache (99th) Selective Replication (99th)

Tail#latency

3.85x improvement for 100 MB

0 20 40 60 80

Read Latency (ms)

EC-Cache, �=0EC-Cache, �=1Selective Replication

Role'of'addi?onal'reads'(Δ)

0 20 40 60 80

Read Latency (ms)

EC-Cache, �=0EC-Cache, �=1Selective Replication

Significant degradation in tail latency without additional reads (i.e., Δ = 0)

Role'of'addi?onal'reads'(Δ)

Addi?onal'evalua?ons'in'the'paper

• With#background#network#imbalance##

• With#server#failures#

• Write#performance#

• SensiRvity#analysis#for#all#parameters

Summary

• EC.Cache#

. Cluster#cache#employing#erasure#coding#for#load#balancing#and#reducing#read#latencies#

. Demonstrates#new#applicaRon#and#new#goals#for#which#erasure#coding#is#highly#effecRve

Summary

• EC.Cache#

• ImplementaRon#on#Alluxio#

• EvaluaRon#. Load#balancing:#>#3x#improvement#. Median#latency:#>#5x#improvement##. Tail#latency:##>#3x#improvement

Summary

• EC.Cache#

• ImplementaRon#on#Alluxio#

• EvaluaRon#. Load#balancing:#>#3x#improvement#. Median#latency:#>#5x#improvement##. Tail#latency:##>#3x#improvement

Thanks!

EC-Cache Load-balanced, Low-latency Cluster Caching with ... · EC-Cache: Load-balanced,...

Documents

Transcript of EC-Cache Load-balanced, Low-latency Cluster Caching with ... · EC-Cache: Load-balanced,...

“aching In” for SharePoint€¦ · Web Part caching post-cache substitution Office viewing service cache virtual memory disk-based caching BLOB cache page-output cache in-memory

“aching In” for SharePoint...Session overview • Caching 101 • Understanding each of SharePoint’s platform ... • Development-related caching (Web Part cache, ASP.NET cache,

Agenda · 2017-12-14 · • Cache tiering, Flashcache/bCache not work well • Long tail latency is big issue for workloads such as OLTP • Need a caching layer to reduce IO path

Improved Lower Bounds for Coded Caching...M Cache 1 Cache 2 Cache K-1 Cache K Aditya Ramamoorthy Improved Lower Bounds for Coded Caching 3 / 35 Coded Caching Formulation [Maddah-Ali

Register Cache System not for Latency Reduction Purpose

Cache & SpinLocks Udi & Haim. Agenda Caching background –Why do we need caching? –Caching in modern desktop. –Cache writing. –Cache coherence. –Cache.

Caching Strategies - Atlanta PHP 2015 · by the caching layer. Application Cache Database. When updating items, update through the cache store, and it will propagate through to the

In-memory Caching in HDFS Lower latency, same great taste

“Caching In” for SharePoint · 2010-06-13 · Object caching Recommendations Be careful with the Object Cache Size allocation! Cross List Query Cache Changes •Off by default

Optimization in Web Caching: Cache Management, Capacity Planning

Caching CS 31: Intro to Systemsmgagne1/teaching/2016_17/cs31/s… · Caching Terminology •Block: the size of a single cache data storage unit •Data gets transferred into cache

Cache-as-a-Service for client-side cloud caching: Models ...

Caching and Microsoft Distributed Cache (aka "Velocity")

Request-Oriented Durable Write Caching for …Request-Oriented Durable Write Caching for Application Performance Non-volatile Write Cache • Volatile DRAM cache is ineffective for

A Scalable Low-Latency Cache Invalidation Strategy for ...danr/courses/6762/Spring01/... · Caching frequently accessed data items on the client side is an effective technique to

LATTE-CC: Latency Tolerance Aware Adaptive Cache ...faculty.engineering.asu.edu/.../12/Arunkumar_LATTE-CC_presentation.pdf · LATTE-CC: Latency Tolerance Aware Adaptive Cache Compression

Rails HTML Fragment Caching with Cache Rocket

Decoupled Compressed Cache: Exploiting Spatial Locality for Energy-Optimized Compressed Caching

HTTP Caching & Cache-Busting for Content Publishers

RIPQ: Advanced Photo Caching on Flash for Facebook · cludes two caching layers: an Edge cache layer and an Origin cache. At each cache site, individual photo ob-jects are hashed