Cache Sketches: Using Bloom Filters and Web Caching Against Slow Load Times
3 likes12,640 views
The document discusses using Bloom filters and cache sketches to enable caching of dynamic content across the web caching hierarchy. A cache sketch is a compact probabilistic data structure that allows clients and servers to track cache invalidations and revalidate cached data. This approach aims to keep cached data fresh while minimizing network requests. It could enable low-latency delivery of dynamic content from ubiquitous caches like content delivery networks and browsers.
![ The „Bloom filter principle“:
“Wherever a list or set is used, and space is at a premium,
consider using a Bloom filter if the effect of false positives can be
mitigated.”
Bloom filter Concepts
Compact Probabilistic Sets
A. Broder und M. Mitzenmacher, „Network applications
of bloom filters: A survey“, Internet Mathematics, 2004.
def insert(obj):
for each position in hashes(obj):
bits[position] = 1
def contains(obj):
for each position in hashes(obj):
if bits[position] == 0:
return false;
return true
Bit array of length m
k independent hash functions
insert(obj): add to set
contains(obj):
Always returns true if the
element was inserted
Might return true even
though it was not inserted
(false positive)](https://image.slidesharecdn.com/webperformancemeetup-public-160419091248/85/Cache-Sketches-Using-Bloom-Filters-and-Web-Caching-Against-Slow-Load-Times-35-320.jpg)
![Idea:
1. Estimate average time to next write 𝐸[𝑇 𝑤] for each record
2. Weight 𝐸[𝑇 𝑤] using the cache miss rate
TTL Estimation
Determining the best TTL
Client
Server
Reads
Misses
λm: Miss Rate
λw: Write Rate
collect
TTL
per record
λm λw
Caches
Writes
~ Poisson
TTL Estimator
Objective:
-maximize Cache Hits
-minimize Purges
-minimize Stale Reads
-bound Cache Sketch
false positive rate
Writes
~ Poisson](https://image.slidesharecdn.com/webperformancemeetup-public-160419091248/85/Cache-Sketches-Using-Bloom-Filters-and-Web-Caching-Against-Slow-Load-Times-70-320.jpg)
![Idea:
1. Estimate average time to next write 𝐸[𝑇 𝑤] for each record
2. Weight 𝐸[𝑇 𝑤] using the cache miss rate
TTL Estimation
Determining the best TTL
Client
Server
Reads
Misses
λm: Miss Rate
λw: Write Rate
collect
TTL
per record
λm λw
Caches
Writes
~ Poisson
TTL Estimator
Objective:
-maximize Cache Hits
-minimize Purges
-minimize Stale Reads
-bound Cache Sketch
false positive rate
Writes
~ Poisson
Good TTLs small Bloom filter
TTL < TTLmin no caching of write-
heavy objects](https://image.slidesharecdn.com/webperformancemeetup-public-160419091248/85/Cache-Sketches-Using-Bloom-Filters-and-Web-Caching-Against-Slow-Load-Times-71-320.jpg)
![The Cache Sketch
Summary
Static Data Mutable Objects
{
"id":"/db/Todo/b5d9bef9-
6c1f-46a5-…",
"version":1,
"acl":null,
"listId":"7b92c069-…",
"name":"Test",
"activities":[],
"active":true,
"done":false
}
Queries/Aggregates
max-age=31557600
Immutability ideal for
static web caching:
Cache Sketch for browser
cache, proxies and ISP
caches
Invalidations for CDNs and
reverse proxies
SELECT TOP 4,
WHERE tag=„x“
How to do this?](https://image.slidesharecdn.com/webperformancemeetup-public-160419091248/85/Cache-Sketches-Using-Bloom-Filters-and-Web-Caching-Against-Slow-Load-Times-76-320.jpg)
![Setting: query results can either be represented as
references (id-list) or full results (object-lists)
Approach: Cost-based decision model that weighs
expected round-trips vs expected invalidations
Ongoing Research: Reinforcement learning of decisions
Learning Representations
Determining Optimal TTLs and Cacheability
[𝑖𝑑1, 𝑖𝑑2, 𝑖𝑑3]
Object-ListsId-Lists
[ 𝑖𝑑: 1, 𝑣𝑎𝑙: ′𝑎′
, 𝑖𝑑: 2, 𝑣𝑎𝑙: ′𝑏′ ,
{𝑖𝑑: 3, 𝑣𝑎𝑙: ′𝑐′}]
Less Invalidations Less Round-Trips](https://image.slidesharecdn.com/webperformancemeetup-public-160419091248/85/Cache-Sketches-Using-Bloom-Filters-and-Web-Caching-Against-Slow-Load-Times-82-320.jpg)
Ad
More Related Content
What's hot (20)
Similar to Cache Sketches: Using Bloom Filters and Web Caching Against Slow Load Times (20)
Ad
Recently uploaded (20)
Ad
Cache Sketches: Using Bloom Filters and Web Caching Against Slow Load Times
- 1. Cache Sketches Using Bloom Filters and Web Caching Against Slow Load Times Felix Gessert, Florian Bücklers {fg,fb}@baqend.com @baqendcom
- 2. Who we are Research Project since 2010 Backend-as-a-Service Startup since 2014 Felix Gessert, Florian Bücklers
- 3. Cache Sketch: Research Approach Using Web Caching in Applications Introduction Main Part Conclusions Web Performance: State of the Art
- 5. Average: 9,3s Why performance matters Loading… -1% Revenue 100 ms
- 6. Average: 9,3s Why performance matters Loading… -1% Revenue -9% Visitors 400 ms
- 7. Average: 9,3s Why performance matters Loading… -1% Revenue -9% Visitors 500 ms -20% Traffic
- 8. Average: 9,3s Why performance matters Loading… -1% Revenue -9% Visitors -20% Traffic 1s -7% Conversions
- 9. An Average Website Some Statistics http://httparchive.org/
- 10. An Average Website Some Statistics http://httparchive.org/
- 11. An Average Website Some Statistics http://httparchive.org/
- 12. If perceived speed is such an important factor ...what causes slow page load times?
- 13. The Problem Three Bottlenecks: Latency, Backend & Frontend High Latency Backend Frontend
- 14. Achieve a fast render of the page by: ◦ Reducing the critical resources needed ◦ Reducing the critical bytes which must be transferred ◦ Loading JS, CSS and HTML templates asynchronously ◦ Rendering the page progressively ◦ Minifying & Concatenating CSS, JS and images Frontend Performance Break-down of the Critical Rendering Path Google Developers, Web Fundamentals https://developers.google.com/web/fundamentals/performance/critical-rendering-path/analyzing-crp.
- 15. Well known problem & good tooling: ◦ Optimizing CSS (postcss) ◦ Concatenating CSS and JS (processhtml) ◦ Minification and Compression (cssmin, UglifyJS, Google Closure, imagemin) ◦ Inline the critical CSS (addyosmani/critical) ◦ Hash assets to make them cacheable (gulp-rev-all) Frontend Performance Tools to improve your page load
- 16. Network Performance Break down of a single resource load DNS Lookup ◦ Every domain has its own DNS lookup Initial connection ◦ TCP makes a three way handshake 2 roundtrips ◦ SSL connections have a more complex handshake +2 roundtrips Time to First Byte ◦ Depends heavily on the distance between client and the backend ◦ Includes the time the backend needs to render the page Session lookups, Database Queries, Template rendering … Content Download ◦ Files have a high transfer time on new connections, since the initial congestion window is small many roundtrips
- 17. Network Performance Common Tuning Knobs Persistent connections, if possible HTTP/2 Avoid redirects Explicit caching headers (no heuristic caching) Content Delivery Networks ◦ To reduce the distance between client and server ◦ To cache images, CSS, JS ◦ To terminate SSL early and optimized Single Page Apps: ◦ Small initial page that loads additional parts asynchronously ◦ Cacheable HTML templates + load dynamic data ◦ Only update sections of the page during navigation
- 18. Network Latency: Impact I. Grigorik, High performance browser networking. O’Reilly Media, 2013.
- 19. Network Latency: Impact I. Grigorik, High performance browser networking. O’Reilly Media, 2013. 2× Bandwidth = Same Load Time ½ Latency ≈ ½ Load Time
- 20. Backend Performance Scaling your backend Horizontally scalable databases (e.g. “NoSQL”) ◦ Replication ◦ Sharding ◦ Failover Load Balancer Application Server Database Stateless session handling Minimize shared state Efficient Code & IO Load Balancing Auto-scaling Failover
- 21. Polaris: Idea: construct graph that captures real read/write and write/write JS/CSS dependencies Improvement: ~30% depending on RTT and bandwidth Limitation: cannot deal with non-determinism, requires server to generate a dependency graph for each client view Research Approaches Two Examples Netravali, Ravi, James Mickens, et al. Polaris: Faster Page Loads Using Fine-grained Dependency Tracking, NSDI 2016
- 22. Shandian: Idea: Proxy is more powerful than browser, especially mobile evaluate page on proxy Improvement: ~50% for slow Android device Limitation: needs modified browser, only useful for slow devices Research Approaches Two Examples Wang, Xiao Sophia, Arvind Krishnamurthy, and David Wetherall. "Speeding up Web Page Loads with Shandian." NSDI 2016. Client Proxy
- 23. Shandian: Idea: Proxy is more powerful than browser especially mobile -> evaluate page on proxy Improvement: ~50% for slow Android device Limitation: needs modified browser, only useful for slow devices Other Research Approaches Two Examples Wang, Xiao Sophia, Arvind Krishnamurthy, and David Wetherall. "Speeding up Web Page Loads with Shandian." NSDI 2016. Client Proxy Many good ideas in current research, but: o Only applicable to very few use cases o Mostly require modified browsers o Small performance improvements
- 24. Performance: State of the Art Summarized Frontend Latency Backend • Doable with the right set of best practices • Good support through build tools • Caching and CDNs help, but a considerable effort and only for static content • Many frameworks and platforms • Horizontal scalability is very difficult
- 25. Performance: State of the Art Summarized Frontend Latency Backend • Easy with the right set of best practices • Good support through build tools • Caching and CDNs help, but large effort and only for static content • Many frameworks and platforms • Horizontal scalability is very difficult Good Resources: Good Tools: https://developers.google.com/web/fundamentals/performance/?hl=en https://www.udacity.com/course/website-performance-optimization--ud884chimera.labs.oreilly.com/ books/1230000000545 shop.oreilly.com/produc t/0636920033578.do https://developers.google.com/speed/ pagespeed/ https://gtmetrix.com http://www.webpagetest.org/
- 26. Performance: State of the Art Summarized Frontend Latency Backend • Doable with the right set of best practices • Good support through build tools • Caching and CDNs help, but large effort and only for static content • Many frameworks and platforms • Horizontal scalability is very difficult How to cache & scale dynamic content?
- 27. Cache Sketch: Research Approach Using Web Caching in Applications Introduction Main Part Conclusions Web Performance: State of the Art
- 28. Goal: Low-Latency for Dynamic Content By Serving Data from Ubiquitous Web Caches Low Latency Less Processing
- 29. In a nutshell Problem: changes cause stale data
- 30. Stale Data In a nutshell Problem: changes cause stale data
- 31. In a nutshell Solution: Proactively Revalidate Data Cache Sketch (Bloom filter) updateIs still fresh? 1 0 11 0 0 10 1 1
- 32. Innovation Solution: Proactively Revalidate Data F. Gessert, F. Bücklers, und N. Ritter, „ORESTES: a Scalable Database-as-a-Service Architecture for Low Latency“, in CloudDB 2014, 2014. F. Gessert und F. Bücklers, „ORESTES: ein System für horizontal skalierbaren Zugriff auf Cloud-Datenbanken“, in Informatiktage 2013, 2013. F. Gessert, S. Friedrich, W. Wingerath, M. Schaarschmidt, und N. Ritter, „Towards a Scalable and Unified REST API for Cloud Data Stores“, in 44. Jahrestagung der GI, Bd. 232, S. 723–734. F. Gessert, M. Schaarschmidt, W. Wingerath, S. Friedrich, und N. Ritter, „The Cache Sketch: Revisiting Expiration-based Caching in the Age of Cloud Data Management“, in BTW 2015. F. Gessert und F. Bücklers, Performanz- und Reaktivitätssteigerung von OODBMS vermittels der Web- Caching-Hierarchie. Bachelorarbeit, 2010. F. Gessert und F. Bücklers, Kohärentes Web-Caching von Datenbankobjekten im Cloud Computing. Masterarbeit 2012. W. Wingerath, S. Friedrich, und F. Gessert, „Who Watches the Watchmen? On the Lack of Validation in NoSQL Benchmarking“, in BTW 2015. M. Schaarschmidt, F. Gessert, und N. Ritter, „Towards Automated Polyglot Persistence“, in BTW 2015. S. Friedrich, W. Wingerath, F. Gessert, und N. Ritter, „NoSQL OLTP Benchmarking: A Survey“, in 44. Jahrestagung der Gesellschaft für Informatik, 2014, Bd. 232, S. 693–704. F. Gessert, „Skalierbare NoSQL- und Cloud-Datenbanken in Forschung und Praxis“, BTW 2015
- 33. Client Expiration- based Caches Invalidation- based Caches Request Path Server/DB Cache Hits Browser Caches, Forward Proxies, ISP Caches Content Delivery Networks, Reverse Proxies Expiration-based Caches: An object x is considered fresh for TTLx seconds The server assigns TTLs for each object Invalidation-based Caches: Expose object eviction operation to the server Web Caching Concepts Invalidation- and expiration-based caches
- 34. Classic Web Caching: Example A tiny image resizer Desktop Mobile Tablet Resized once Cached and delivered many times
- 35. The „Bloom filter principle“: “Wherever a list or set is used, and space is at a premium, consider using a Bloom filter if the effect of false positives can be mitigated.” Bloom filter Concepts Compact Probabilistic Sets A. Broder und M. Mitzenmacher, „Network applications of bloom filters: A survey“, Internet Mathematics, 2004. def insert(obj): for each position in hashes(obj): bits[position] = 1 def contains(obj): for each position in hashes(obj): if bits[position] == 0: return false; return true Bit array of length m k independent hash functions insert(obj): add to set contains(obj): Always returns true if the element was inserted Might return true even though it was not inserted (false positive)
- 36. Bloom filter Concepts Visualized 1 m 0 0 0 0 0 0 0 0 0 0 Empty Bloom Filter 1 m 0 1 0 0 0 0 1 0 0 1 Insert x h1h2 h3 x 1 m 1 1 0 0 1 0 1 0 1 1 Insert y h1h2 h3 y Query x 1 m 1 1 0 0 1 0 1 0 1 1 h1h2 h3 =1? n y contained
- 37. Bloom filter Concepts False Positives False-Positive for z Query z 1 m 1 1 0 0 1 0 1 0 1 1 h1h2h3 =1? y contained 𝑓 ≈ 1 − 𝑒− ln 2 𝑘 ≈ 0.6185 𝑚 𝑛 The false positive rate depends on the bits m and the inserted elements n: For f=1% the required bits per element are: 2.081 ln(1/0.01) = 9.5
- 38. Our Bloom filter Open Source Implementation
- 39. Our Bloom filters Example: Redis-backed Counting Bloom Filter Redis-backed Bloom filters: ◦ Can be shared by many servers ◦ Highly efficient through Redis‘ bitwise operations ◦ Tunable persistence Counting Bloom Filters: use counters instead of bits to also allow removals ◦ Stores the materialized Bloom filter for fast retrieval 0 2 0 0 1 0 3 0 1 1COUNTS 0 1 0 0 1 0 1 0 1 1BITS
- 40. Idea: use standard HTTP Caching for query results and records Problems: The Cache Sketch approach Caching Dynamic Data How to keep the browser cache up-to- date? How to automatically cache dynamic data in a CDN? When is data cacheable and for how long approximately?
- 42. Orestes Architecture Infrastructure Content-Delivery- Network Backend-as-a-Service Middleware: Caching, Transactions, Schemas, Invalidation Detection, …
- 46. Client Expiration- based Caches Invalidation- based Caches Request Path Server/DB Cache Hits Browser Caches, Forward Proxies, ISP Caches Content Delivery Networks, Reverse Proxies at connect Periodic every Δ seconds at transaction begin 2 31 Invalidations, Records Needs Invalidation? Needs Revalidation? The Cache Sketch approach Letting the client handle cache coherence Staleness-MinimizationInvalidation-Minimization Client Cache Sketch 10101010 Bloom filter Server Cache Sketch 10201040 10101010 Counting Bloom Filter Non-expired Record Keys Report Expirations and Writes
- 47. The End to End Path of Requests The Caching Hierarchy Client- (Browser-) Cache Proxy Caches ISP Caches CDN Caches Reverse- Proxy Cache Miss Hit Miss Miss Miss Miss Orestes DB.posts.get(id) JavaScript
- 48. The End to End Path of Requests The Caching Hierarchy Client- (Browser-) Cache Proxy Caches ISP Caches CDN Caches Reverse- Proxy Cache Miss Hit Miss Miss Miss Miss Orestes GET /db/posts/{id} HTTP
- 49. The End to End Path of Requests The Caching Hierarchy Client- (Browser-) Cache Proxy Caches ISP Caches CDN Caches Reverse- Proxy Cache Miss Hit Miss Miss Miss Miss Orestes Cache-Hit: Return Object Cache-Miss or Revalidation: Forward Request
- 50. The End to End Path of Requests The Caching Hierarchy Client- (Browser-) Cache Proxy Caches ISP Caches CDN Caches Reverse- Proxy Cache Miss Hit Miss Miss Miss Miss Orestes Return record from DB with caching TTL
- 51. The End to End Path of Requests The Caching Hierarchy Client- (Browser-) Cache Proxy Caches ISP Caches CDN Caches Reverse- Proxy Cache Miss Hit Miss Miss Miss Miss Orestes Updated by Cache Sketch Updated by the server
- 52. Let ct be the client Cache Sketch generated at time t, containing the key keyx of every record x that was written before it expired in all caches, i.e. every x for which holds: The Client Cache Sketch ∃ 𝑟(𝑥, 𝑡 𝑟, 𝑇𝑇𝐿), 𝑤 𝑥, 𝑡 𝑤 ∶ 𝑡 𝑟 + 𝑇𝑇𝐿 > 𝑡 > 𝑡 𝑤 > 𝑡 𝑟 k hash functions m Bloom filter bits 1 0 0 1 1 0 1 1 h1 hk ...keyfind(key) Client Cache Sketch Bits = 1 no yes GET request Revalidation Cache Hit Miss key key
- 53. Let ct be the client Cache Sketch generated at time t, containing the key keyx of every record x that was written before it expired in all caches, i.e. every x for which holds: The Client Cache Sketch ∃ 𝑟(𝑥, 𝑡 𝑟, 𝑇𝑇𝐿), 𝑤 𝑥, 𝑡 𝑤 ∶ 𝑡 𝑟 + 𝑇𝑇𝐿 > 𝑡 > 𝑡 𝑤 > 𝑡 𝑟 k hash functions m Bloom filter bits 1 0 0 1 1 0 1 1 h1 hk ...keyfind(key) Client Cache Sketch Bits = 1 no yes GET request Revalidation Cache Hit Miss key key JavaScript Bloomfilter: ~100 LOCs ~1M lookups per second
- 54. Let ct be the client Cache Sketch generated at time t, containing the key keyx of every record x that was written before it expired in all caches, i.e. every x for which holds: The Client Cache Sketch ∃ 𝑟(𝑥, 𝑡 𝑟, 𝑇𝑇𝐿), 𝑤 𝑥, 𝑡 𝑤 ∶ 𝑡 𝑟 + 𝑇𝑇𝐿 > 𝑡 > 𝑡 𝑤 > 𝑡 𝑟 k hash functions m Bloom filter bits 1 0 0 1 1 0 1 1 h1 hk ...keyfind(key) Client Cache Sketch Bits = 1 no yes GET request Revalidation Cache Hit Miss key key JavaScript Bloomfilter: ~100 LOCs ~1M lookups per second Guarantee: data is never stale for more than the age of the Cache Sketch
- 55. The Server Cache Sketch Scalable Implementation Performance > 200k ops per second: Add keyx if x unexpired and write occured Remove x from Blom filter when expired Load Bloom filter
- 56. 1 4 020 Browser Cache CDN Clients load the Cache Sketch at connection Every non-stale cached record can be reused without degraded consistency Faster Page Loads1
- 57. 1 4 020 Browser Cache CDN Clients load the Cache Sketch at connection Every non-stale cached record can be reused without degraded consistency Faster Page Loads1
- 58. 1 4 020 Browser Cache CDN Clients load the Cache Sketch at connection Every non-stale cached record can be reused without degraded consistency Faster Page Loads1
- 59. 1 4 020 purge(obj) hashB(oid)hashA(oid) 3 Browser Cache CDN 1 Clients load the Cache Sketch at connection Every non-stale cached record can be reused without degraded consistency Faster Page Loads1
- 60. 1 4 020 31 1 110 Flat(Counting Bloomfilter) Browser Cache CDN 1 Clients load the Cache Sketch at connection Every non-stale cached record can be reused without degraded consistency Faster Page Loads1
- 61. 1 4 020 31 1 110 hashB(oid)hashA(oid) Browser Cache CDN 1 Clients load the Cache Sketch at connection Every non-stale cached record can be reused without degraded consistency Faster Page Loads1
- 62. 1 4 020 31 1 110 hashB(oid)hashA(oid) Browser Cache CDN 1 Clients load the Cache Sketch at connection Every non-stale cached record can be reused without degraded consistency Faster Page Loads1
- 63. 1 4 020 31 1 110 Browser Cache CDN 1 Clients load the Cache Sketch at connection Every non-stale cached record can be reused without degraded consistency Faster Page Loads1
- 64. 1 4 020 hashB(oid)hashA(oid) 1 1 110 Browser Cache CDN Clients load the Cache Sketch at connection Every non-stale cached record can be reused without degraded consistency Faster Page Loads1
- 65. 1 4 020 hashB(oid)hashA(oid) 1 1 110 Browser Cache CDN Clients load the Cache Sketch at connection Every non-stale cached record can be reused without degraded consistency Faster Page Loads1 𝑓 ≈ 1 − 𝑒− 𝑘𝑛 𝑚 𝑘 𝑘 = ln 2 ⋅ ( 𝑛 𝑚 ) False-Positive Rate: Hash- Functions: With 20.000 distinct updates and 5% error rate: 11 KByte
- 66. Solution: Δ-Bounded Staleness ◦ Clients refresh the Cache Sketch so its age never exceeds Δ → Consistency guarantee: Δ-atomicity Faster CRUD Performance Client Expiration- based Caches Invalidation- based Caches Server Cache Sketch ctQuery Cache Sketch fresh records Revalidate record & Refresh Cache Sketch Cache Hits Fresh record & new Cache Sketch -time t -time t + Δ 2
- 67. Scalable ACID Transcations Solution: Conflict-Avoidant Optimistic Transactions ◦ Cache Sketch fetched with transaction begin ◦ Cached reads → Shorter transaction duration → less aborts 3 Cache Cache Cache REST-Server REST-Server REST-Server DB Coordinator Client Begin Transaction Bloom Filter 1 validation 4 5Writes (Public) Read all prevent conflicting validations Committed OR aborted + stale objects Commit: readset versions & writeset 3 Reads 2
- 68. Scalable ACID Transcations Novelty: ACID transactions on sharded DBs like MongoDB Current Work: DESY and dCache building a scalable namespace for their file system on this 3 With Caching Without Caching
- 69. Problem: if TTL ≫ time to next write, then it is contained in Cache Sketch unnecessarily long TTL Estimator: finds „best“ TTL Trade-Off: TTL Estimation Determining the best TTL and cacheability Longer TTLsShorter TTLs • Higher cache-hit rates • more invalidations • less invalidations • less stale reads
- 70. Idea: 1. Estimate average time to next write 𝐸[𝑇 𝑤] for each record 2. Weight 𝐸[𝑇 𝑤] using the cache miss rate TTL Estimation Determining the best TTL Client Server Reads Misses λm: Miss Rate λw: Write Rate collect TTL per record λm λw Caches Writes ~ Poisson TTL Estimator Objective: -maximize Cache Hits -minimize Purges -minimize Stale Reads -bound Cache Sketch false positive rate Writes ~ Poisson
- 71. Idea: 1. Estimate average time to next write 𝐸[𝑇 𝑤] for each record 2. Weight 𝐸[𝑇 𝑤] using the cache miss rate TTL Estimation Determining the best TTL Client Server Reads Misses λm: Miss Rate λw: Write Rate collect TTL per record λm λw Caches Writes ~ Poisson TTL Estimator Objective: -maximize Cache Hits -minimize Purges -minimize Stale Reads -bound Cache Sketch false positive rate Writes ~ Poisson Good TTLs small Bloom filter TTL < TTLmin no caching of write- heavy objects
- 72. End-to-End Example Browser Browser Cache CDN Cache Server Client Cache Sketch Server Cache Sketch b={x2} t = {(x2, t2), (x3, t3),(x1, t1)} b= INITIALIZE c={(x2,t2),(x3,t3)} c={(x1,t1) b={x2} CONNECT bt0={x2} READ x3 QUERY x3 RESPONSE false GET x3 RESPONSE x3 QUERY x2 RESPONSE true READ x2 REVALIDATE x2 c={(x3,t3)} RESPONSE x2,t4 c={(x2,t4),(x3,t3)} c={(x2,t4)} REPORT READ x2,t4 b={x2} t = {(x2, t4), (x3, t3),(x1, t1)} RESPONSE inv=true WRITE x1 PUT x1=v REPORT WRITE x1 RESPONSE ok INVALIDATE x1 b={x1,x2} t = {(x2, t4), (x3, t3),(x1, t1)}
- 73. Consistency What are the guarantees? Consistency Level How Δ-atomicity (staleness never exceeds Δ seconds) Controlled by age of Cache Sketch Montonic Writes Guaranteed by database Read-Your-Writes and Montonic Reads Cache written data and most recent versions Always Opt-in Causal Consistency If timestamp older than Cache Sketch it is given, else revalidate Strong Consistency (Linearizability) Explicit Revalidation (Cache Miss)
- 74. Performance CDN Northern California Client MongoDBOrestes Ireland Setup: Page load times with cached initialization (simulation): Average Latency for YCSB Workloads A and B (real): With Facebook‘s cache hit rate: >2,5x improvement 95% Read 5% Writes 5x latency improvement
- 75. Cache all GET requests Authorize the user on protected resources Validate & renew session tokens of users Varnish and Fastly What we do on the edge Reject rate limited users Handle CORS pre-flight requests Access-Control-* Collect access logs & report failures
- 76. The Cache Sketch Summary Static Data Mutable Objects { "id":"/db/Todo/b5d9bef9- 6c1f-46a5-…", "version":1, "acl":null, "listId":"7b92c069-…", "name":"Test", "activities":[], "active":true, "done":false } Queries/Aggregates max-age=31557600 Immutability ideal for static web caching: Cache Sketch for browser cache, proxies and ISP caches Invalidations for CDNs and reverse proxies SELECT TOP 4, WHERE tag=„x“ How to do this?
- 77. Continuous Query Matching Generalizing the Cache Sketch to query results Main challenge: when to invalidate? ◦ Objects: for every update and delete ◦ Queries: as soon as the query result changes How to detect query result changes in real-time?
- 78. Query Caching Example Add, Change, Remove all entail an invalidation and addition to the cache sketch SELECT * FROM posts WHERE tags CONTAINS 'b' Query Predicate P Cached Query Result Q 𝑜𝑏𝑗1 ∈ 𝐐 𝑜𝑏𝑗2 ∈ 𝐐 Change Add Remove
- 79. InvaliDB Architecture ORESTES Create Update Delete Pub-Sub Pub-Sub 1 0 11 0 0 10 1 1 Fresh Cache Sketch Continuous Queries (Websockets) Fresh Caches Polyglot Views Felix Gessert, Michael Schaarschmidt, Wolfram Wingerath, Steffen Friedrich, Norbert Ritter: ***. Under Submission.
- 80. InvaliDB Matching on Apache Storm Apache Storm: • „Hadoop of Real-Time“ • Low-Latency Stream Processing • Custom Java-based Topologies InvaliDB goals: • Scalability, Elasticity, Low latency, Fault- tolerance
- 81. Latency mostly < 15ms, scales linearly w.r.t. number of servers and number of tables Query Matching Performance Latency of detecting invalidations
- 82. Setting: query results can either be represented as references (id-list) or full results (object-lists) Approach: Cost-based decision model that weighs expected round-trips vs expected invalidations Ongoing Research: Reinforcement learning of decisions Learning Representations Determining Optimal TTLs and Cacheability [𝑖𝑑1, 𝑖𝑑2, 𝑖𝑑3] Object-ListsId-Lists [ 𝑖𝑑: 1, 𝑣𝑎𝑙: ′𝑎′ , 𝑖𝑑: 2, 𝑣𝑎𝑙: ′𝑏′ , {𝑖𝑑: 3, 𝑣𝑎𝑙: ′𝑐′}] Less Invalidations Less Round-Trips
- 83. What is the impact of query caching?
- 84. What is the impact of query caching? Insight: Query Caching = Real-Time Apps
- 86. Continuous Queries Complementing Cached Queries Same streaming architecture can similarly notify the browser about query result changes Application Pattern: Streaming Layer Insert … tag=‘b‘ … Subscribe tag=‘b‘ Orestes Initial Page Load using Cached Queries Critical data declaratively specified and proactively pushed via websockets
- 87. Continuous Query API Subscribing to database updates var stream = DB.News.find().stream(); stream.on("add", onNews); stream.on("remove", onRemove);
- 88. Orestes: DB-independent Backend-as-a-Service Cache Sketch Approach: ◦ Client decides when to revalidate, server invalidates CDN ◦ Cache Sketch = Bloom filter of stale IDs ◦ Compatible with end-to-end ACID transactions ◦ Query change detection in real-time Summary 0 1 0 0 1 0 1 0 1 1 1 1 0 0 0 0 0 0 1 1 HTTP Caching Cache Sketch TTL Estimation RT Query Matching Invali- dations
- 89. Cache Sketch: Research Approach Using Web Caching in Applications Introduction Main Part Conclusions Web Performance: State of the Art
- 90. Team: Felix Gessert, Florian Bücklers, Hannes Kuhlmann, Malte Lauenroth, Michael Schaarschmidt 19. August 2014 Orestes Caching Technology as a Backend-as-a-Service
- 91. Page-Load Times What impact does caching have in practice?0,7s 1,8s 2,8s 3,6s 3,4s CALIFORNIEN 0,5s 1,8s 2,9s 1,5s 1,3s FRANKFURT 0,6s 3,0s 7,2s 5,0s 5,7s SYDNEY 0,5s 2,4s 4,0s 5,7s 4,7s TOKYO
- 92. Live Demo: Using Caching in Practice
- 93. Ziel mit InnoRampUp Want to try Baqend? Download Community Edition Free Baqend Cloud instance
Editor's Notes
- #5: -überrascht -eigentlich sollte das jetzt schon geladen sein, das dauert sonst nicht so lange
- #6: -Das (was?) waren 9,3 s – so lange lädt eine durchschnittliche E-Commerce Webseite -Selbst kleinste Ladezeitverzögerungen haben immense Auswirkungen auf die Nutzerzufriedenheit und den Geschäftserfolg -Zahllose Studien haben diese Effekte quantifiziert, hier sind einige der bekanntesten -Amazon, 800 Mio. verlorener Umsatz -Yahoo, weil Nutzer unzufriedener sind -Google, 500ms durch attraktivere Inhalte und trotzdem Rückgang des Umsatzes und der Aufrufe -Aberdeen Group, Marktforschungsinstitut, d.h. 7% weniger Besucher werden zu Kunden -Neben diesen abstrakten Zahlen haben wir mit Unternehmen wie GoodGame Studios und WLW gesprochen
- #7: -Das (was?) waren 9,3 s – so lange lädt eine durchschnittliche E-Commerce Webseite -Selbst kleinste Ladezeitverzögerungen haben immense Auswirkungen auf die Nutzerzufriedenheit und den Geschäftserfolg -Zahllose Studien haben diese Effekte quantifiziert, hier sind einige der bekanntesten -Amazon, 800 Mio. verlorener Umsatz -Yahoo, weil Nutzer unzufriedener sind -Google, 500ms durch attraktivere Inhalte und trotzdem Rückgang des Umsatzes und der Aufrufe -Aberdeen Group, Marktforschungsinstitut, d.h. 7% weniger Besucher werden zu Kunden -Neben diesen abstrakten Zahlen haben wir mit Unternehmen wie GoodGame Studios und WLW gesprochen
- #8: -Das (was?) waren 9,3 s – so lange lädt eine durchschnittliche E-Commerce Webseite -Selbst kleinste Ladezeitverzögerungen haben immense Auswirkungen auf die Nutzerzufriedenheit und den Geschäftserfolg -Zahllose Studien haben diese Effekte quantifiziert, hier sind einige der bekanntesten -Amazon, 800 Mio. verlorener Umsatz -Yahoo, weil Nutzer unzufriedener sind -Google, 500ms durch attraktivere Inhalte und trotzdem Rückgang des Umsatzes und der Aufrufe -Aberdeen Group, Marktforschungsinstitut, d.h. 7% weniger Besucher werden zu Kunden -Neben diesen abstrakten Zahlen haben wir mit Unternehmen wie GoodGame Studios und WLW gesprochen
- #9: -Das (was?) waren 9,3 s – so lange lädt eine durchschnittliche E-Commerce Webseite -Selbst kleinste Ladezeitverzögerungen haben immense Auswirkungen auf die Nutzerzufriedenheit und den Geschäftserfolg -Zahllose Studien haben diese Effekte quantifiziert, hier sind einige der bekanntesten -Amazon, 800 Mio. verlorener Umsatz -Yahoo, weil Nutzer unzufriedener sind -Google, 500ms durch attraktivere Inhalte und trotzdem Rückgang des Umsatzes und der Aufrufe -Aberdeen Group, Marktforschungsinstitut, d.h. 7% weniger Besucher werden zu Kunden -Neben diesen abstrakten Zahlen haben wir mit Unternehmen wie GoodGame Studios und WLW gesprochen
- #13: -Diese und andere Studien beweisen also, dass langsame Apps und Webseiten allen wichtigen Kennzahlen schaden -Die Frage ist also: wenn das Problem schon so lange und genau bekannt ist - warum ist es bisher technisch ungelöst?
- #14: -Hier sehen wir einen Endnutzer der aus den USA auf eine europäische Anwendung zugreift -Schlechte Ladezeiten entstehen durch zwei technische Engpässe 1. Wenn ein Nutzer auf eine Webanwendung zu, muss zunächst ein Web-Server das sogenannte „Backend“ die Webseite generieren. Dabei entsteht eine hohe Verarbeitungszeit beim Zusammenstellen der Inhalte aus einer Datenbank. 2. Diese Webseite und alle Ressourcen, die sie enthält –z.B. Bilder- müssen über das Internet zum Nutzer übertragen werden. Dadurch entsteht eine als „Latenz“ bezeichnete Übertragungszeit, die um so höher ist, je weiter der Nutzer von dem Backend entfernt ist. Diese Latenz und nicht die Bandbreite bestimmen die wahrgenommenen Ladezeiten. - Diese beiden Engpässe können wir durch unser Produkt Baqend für beliebige Anwendungen lösen
- #29: -Bei unserem Ansatz werden alle Daten nicht nur im Backend sondern auch global verteilt zwischengespeichert, um so dicht wie möglich an Endnutzern positioniert zu sein. Wenn also ein Nutzer die Webanwendung aufruft, ist unabhängig von seinem Standort die Latenz gering Durch die Zwischenspeicher, sogenannte „Caches“, entsteht kein Verarbeitungsaufwand im Backend. Durch unsere Algorithmen können diese existierenden und zahlreich vorhandenen Caches erstmals für alle Anwendungsdaten genutzt werden.
- #30: -Die technische und wissenschaftliche Basis von Baqend beruht auf verschiedenen Innovationen im Bereich Datenbanken und Cloud Computing Die neuen Algorithmen und Architekturen sind durch 4,5 Jahre Forschung und Entwicklung am Institut für Verteilte Systeme und Informationssysteme an der Uni Hamburg entstanden. Kern der Innovation ist eine Technik, die es erlaubt, die bestehende Caching-Infrastruktur auf eine völlig neue Art zu verwenden Beim klassischen Caching werden angefragte Daten automatisch in Caches zwischengespeichert Ein Problem entsteht, wenn Daten geändert werden. Nach der Änderung sind die Einträge in den Caches veraltet. Wenn Nutzer also die Webanwendung aufrufen, erhalten sie veraltete Daten.
- #31: -Die technische und wissenschaftliche Basis von Baqend beruht auf verschiedenen Innovationen im Bereich Datenbanken und Cloud Computing Die neuen Algorithmen und Architekturen sind durch 4,5 Jahre Forschung und Entwicklung am Institut für Verteilte Systeme und Informationssysteme an der Uni Hamburg entstanden. Kern der Innovation ist eine Technik, die es erlaubt, die bestehende Caching-Infrastruktur auf eine völlig neue Art zu verwenden Beim klassischen Caching werden angefragte Daten automatisch in Caches zwischengespeichert Ein Problem entsteht, wenn Daten geändert werden. Nach der Änderung sind die Einträge in den Caches veraltet. Wenn Nutzer also die Webanwendung aufrufen, erhalten sie veraltete Daten.
- #32: -Es gibt zwei Typen von Caches: solche die durch ein Backend aktualisierbar sind und solche die unter keiner Kontrolle stehen -Unsere Lösung verwendet eine spezielle Datenstruktur, über die effizient festgestellt werden kann, welche Daten veraltet sind. Zusätzlich werden bei einer Änderung Daten in kontrollierbaren Caches automatisch aktualisiert Die Webanwendung verwendet daraufhin automatisch den Bloomfilter, um veraltete Daten neu zu laden, wodurch Caches sich selber aktualisieren. Für alle Anwender ist dadurch garantiert, dass sie stets aktuelle Daten erhalten.
- #33: -Die Details dieser Verfahren sind in wissenschaftlichen Publikationen veröffentlicht -Durch die jahrelange Vorarbeit haben wir gegenüber unseren Mitbewerbern einen kaum einzuholenden Vorsprung
- #42: Was ändert sich Client-seitig bzw. für die Anwendungsentwickler?
- #43: Was ändert sich Client-seitig bzw. für die Anwendungsentwickler?
- #44: Was ändert sich Client-seitig bzw. für die Anwendungsentwickler?
- #45: Was ändert sich Client-seitig bzw. für die Anwendungsentwickler?
- #47: Wie unterscheidet sich eine client-seitige Objektanfrage in den Fällen ‚aktuell‘ und ‚stale‘?
- #75: Kernaussage links: Bei steigenden Cache-Hit-Raten werden Seitenladezeiten von Webseiten drastisch reduziert, selbst bei höheren False Positive Rates des Bloom Filters. Nimmt man die mittlere Cache-Hit-Rate bei Facebook-Bildern an (statische Daten) erzielt man mit Orestes eine 2.5-fache Verbesserungen der Ladezeit (dynamische Daten). Kernaussage rechts: Der Yahoo Cloud Serving Benchmark zeigt, dass selbst bei relativ schreiblastigen Workloads signifikante Latenzverbesserungen möglich sind. Bei leselastigen Workloads ist der Effekt noch deutlicher.
- #80: Sollte man das wirklich ‚Architecture‘ überschreiben? Vielleicht besser ‚Principle‘ oder ‚Basic Idea‘ oder ‚Basic Principle‘ … Warum zweimal Pub-Sub? Warum die Pfeile in diese Richtungen? Kann man ‚Websockets‘ weglassen? Was ist Continuous Query? Was ist das grundlegende Prinzip der Wartung von Queries durch den Cache Sketch?
- #82: Was genau ist gemeint, wenn da ‚Query‘ steht? (Statement-Text, Query-ID, Query-Result-Set, …)? Wie werden Queries im Cache Sketch repräsentiert? Nur durch die Ergebnis-Objekte, oder benötigt die Query eigene Einträge? Wie werden ‚Query State Updates‘ repräsentiert? Wieso Redis auf Distribution Layer? Ist Matching reine ‚Prädikatevaluation‘? Was genau ist mit den Begriffen gemeint, die rechts neben ‚Distribution Layer‘ stehen? Wenn initial eine Query geschickt wird, muss diese durch den kompletten Loop? …
- #83: Kernaussage: Der Streaming Layer hat relativ konstante Latenzen bis zu einem Durchsatz von 2 Mio. Matches pro Server pro Sekunde. Das reicht bei 40 Updates/s für 100K simultan gecachte Querys oder Continuous Querys. Besprechen?
- #85: Noch mal komplett durchsprechen?
- #91: Hier fehlen die Queries (und die polyglotten views)
- #93: -Vorstellung: Felix, Baqend GmbH, alle andern
- #94: -Um die Ladezeitvorteile praktisch zu belegen, haben wir als Beispielanwendung eine Newsseite entwickelt Die Anwendung haben wir auf Baqend und den vier wichtigsten Konkurrenzprodukten realisiert und untersucht Dafür haben wir die Ladezeiten für Nutzer aus vier geographischen Standorten gemessen. Aufgrund unser neuen Techniken ist Baqend standortübergreifend stets um mindestens Faktor 2,5 schneller. Selbst wenn Nutzer und Anbieter aus der gleichen Region kommen, sorgt die durch Baqend eingesparte Verarbeitungszeit für einen signifikanten Geschwindigkeitsvorteil.