A Personal Assistant for Web Database Caching

Presentation given at CAiSE 2000, 12th International Conference on Advanced Information Systems Engineering, Stockholm, Sweden, June 2000

ABSTRACT: To improve the performance of web database access for regular users, we have developed a client caching agent, referred to as a personal assistant. In addition to caching strategies based on data characteristics and user specification, the personal assistant dynamically prefetches information based on previously monitored user access patterns. It is part of an overall multi-layered caching scheme where cache coherency is ensured through cooperation with a server-side database caching agent. The personal assistant has been implemented in Java and integrated into the web architecture for the OMS Pro database management system.

Research paper: https://beatsigner.com/publications/a-personal-assistant-for-web-database-caching.pdf

Transcript

1. A Personal Assistant for Web Database Caching Beat Signer, signer@inf.ethz.ch Institute for Information Systems ETH Zurich
2. Overview • Motivation • Internet OMS architecture • Personal Assistant • Cache architecture • Performance measurements • Conclusion
3. 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
4. Internet OMS Architecture Front-End Agent Personal Assistant Session Cache Active Cache Global Cache HTTP Server Database Agent Web Browser OMS Database    Internet
5. 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
6. 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
7. 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 . . . .
8. 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:
9. 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!
10. Cache Administration Tools
11. 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
12. 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
13. 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%
14. 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
15. Future Work • Use similiar prefetching techniques to build an HTTP caching proxy • First prototype running at gordon.inf.ethz.ch:9090