A Personal Assistant for Web Database Caching Beat Signer, [email protected] Institute for Information Systems ETH Zurich 

Overview • Motivation • Internet OMS architecture • Personal Assistant • Cache architecture • Performance measurements • Conclusion 

Motivation • Lack of most browsers to cache dynamically generated web pages • Cooperative client, middle layer and server caches to improve performance • Reduction of query response times by better usage of the available resources 

Internet OMS Architecture Front-End Agent Personal Assistant Session Cache Active Cache Global Cache HTTP Server Database Agent Web Browser OMS Database    Internet 

Cache Requirements • Reduction of response times (latency) • Reduction of idle times (e.g. modem connection) • Cache consistency • Persistence • Flexibility (different user skills) • Active caching component (local prefetching) • Small overhead to maintain cache • Optimal usage of available cache resource 

Personal Assistant Cache Structure Personal Assistant Cache query results images Session Cache query results images Personal Cache query results images Prefetching Cache Persistent Client Cache Short-Term Cache ▪ passive ▪ priority 3 Explicit User Specified Objects ▪ permanent ▪ passive ▪ priority 1 Long-Term Cache ▪ user profile ▪ active ▪ priority 2 disjoint 

Prefetching Cache Statistics LRUB-Cache (fixed size) LRUB-Cache (fixed size) query 1 query 2 query n statistic next query 1 next query 2 next query n next query 3 . . . . statistic next query 1 next query 2 next query n next query 3 . . . . statistic next query 1 next query 2 next query n next query 3 . . . . 

Cache Replacement Strategy • Least recently used (LRU) • Introduce bonus for entries often used in the past but not accessed recently → LRUB 1 0 , ) 1 ( weight i   − + =    i i T H i H : Number of hits for cache entry i i T : Time since last access of cache entry i • Weight for cache entry i defined as follows: 

q1 q3 q5 q9 q2 q6 q4 q7 q8 Advantages of Adaptive Prefetching • Assumption: global cache of size 4 for most frequently used queries → which of the 6 “hot queries” should be cached? q1 q3 q5 q9 q2 q6 q4 q7 q8 q1 q3 q5 q9 q2 q6 q4 q7 q8 • Adaptive prefetching → sliding window mechanism, i.e. cache of size 2 is sufficient! 

Cache Administration Tools 

Average Response Times Average Time Worst Case 0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000 Total Time Query Time Image Time time[ms] Without Personal Assistant With Personal Assistant Average Time Best Case 0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000 Total Time Query Time Image Time time[ms] Without Personal Assistant With Personal Assistant 

Image Response Times Average Image Time Worst Case 0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000 Without Personal Assistant With Personal Assistant time[ms] User 1 User 2 User 3 User 4 Average Image Time Best Case 0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000 Without Personal Assistant With Personal Assistant time[ms] User 1 User 2 User 3 User 4 

Cache Hit Rates • Increased hit rate even in worst case scenario (due to larger caches) • Front-end agent profits from locality of queries in best case scenario Front-End Agent Personal Assistant queries images queries images Worst Case Best Case 13% 4% 33% 29% 29% 28% 75% 68% 

Conclusion • Advantages ▪ increased cache hit rate ▪ reduced response times ▪ adaptation to individual users ▪ easy to use (transparent) ▪ prefetching statistic always up to date • Costs ▪ database agent eventually has to handle an increased number of queries (prefetching) → increased server loads ▪ overhead to maintain cache consistency 

Future Work • Use similiar prefetching techniques to build an HTTP caching proxy • First prototype running at gordon.inf.ethz.ch:9090