Download presentation
Presentation is loading. Please wait.
Published byMiles Barnett Modified over 9 years ago
1
MiddleMan: A Video Caching Proxy Server NOSSDAV 2000 Brian Smith Department of Computer Science Cornell University Ithaca, NY Soam Acharya Inktomi Corporation Foster City, CA
2
VOW ( Video on the Web):1999-2000 Remote sites –eg. CNN, Mars Pathfinder, ESPN –Clinton’s testimony –“micro broadcasting” stations Local sites –corporate intranets - training videos –University-wide lecture distribution
3
Internet Problems With VOW Network unreliability Client heterogeneity Server bottlenecks Content Distribution Networks Only distribute portion of a web site Don’t improve latency as much as.. My solution: cache transmission CNN 28.8/56 Kbps T1 ISP
4
Our Goals Low end, low cost approach Scalable Utilize highly connected network of powerful commodity PCs
5
How Does It Work? P CNN P Video web caching proxy system TCP Coordinator
6
Why is this an attractive idea? Consider a University campus –50-1000 PCs –4 GB disk each –100 MB for caching –5-100 GB aggregate cache System Architecture –Proxies: cache on each end system. Acts as both client and server –Coordinator: manages cache
7
Roadmap Survey Summary Architecture: Detailed system architecture Analysis: Architecture analysis and results Comparison with other designs Conclusion and future direction
8
Characterizing Videos On The Web mid April 1997 - May 1997 about 57000 video titles 100 GB of data Web video size (~ 1 MB) Videos are WORMs
9
Characterizing User Access To Videos On The World Wide Web Traces from an ongoing Enterprise VoW trial: 2 year period 13100 requests 246 titles Video browsing pattern Partial browsing: only 61% of all movie accesses went to completion High temporal locality File size trends …
10
Roadmap Survey Summary Architecture: Detailed system architecture Analysis: Architecture analysis and results Comparison with other designs Conclusion and future direction
11
MiddleMan Design Principles Proxy cluster –proxies + one coordinator per LAN Fragmentation –videos fragmented into equal sized file fragments (1 MB “cache lines”) Partial Video Storage Policy –don’t have to keep entire video lying around –Replace on a block by block basis
12
How It Works I P WWW C P P C P Coordinator Proxy
13
How It Works II P WWW C P P C P Coordinator Proxy
14
LP SP MiddleMan: Actual Architecture C WWW LAN LP Coordinator Local Proxy Storage Proxy SP C Communication Data transfer
15
Linking Multiple Proxy Clusters CCC
16
Roadmap Survey Summary Architecture: Detailed system architecture Analysis: Architecture analysis and results Comparison with other designs Conclusion and future direction
17
Issues To Analyze Local cache size Size of file blocks Caching algorithm Controlling proxy load
18
Performance Analysis (via Simulations) Caching –analyze byte hit rates of various caching algorithms Load Balancing –load analysis on the proxies
19
The Configuration Tested 44 proxies Individual proxy cache size: –50 Mbytes (8.6% of video server size), –25 Mbytes (4.3%) –12 Mbytes (2.1%) Block size: 1 Mbyte Three sub traces: cdt, sm, campus Trace Durations: –6 months –2 years
20
Overall Cdt Cache Performance 12 MB, 2.1% 25 MB, 4.3% 50 MB, 8.6%
21
Caching Conclusion Not much difference in caching algorithm performance –cannot evaluate architecture solely based on byte hit rate –Should consider load balancing behavior
22
Load Balancing How define/measure “load”? –Dynamic: traffic in the past hour, peak # of connections, peak BW –Cumulative: byte traffic through a proxy? tested the following algorithms: –LRU –histLRUpick run LRU-2, LRU-3, LRU-4 in parallel to obtain multiple candidates for block replacement pick the least loaded block
23
Measuring Dynamic Load Balancing Performance P1 P2 P3 # of connections Total # of connections Time connections at (max) proxy # of connections Time Example Proxy Connection Plot # of connections
24
LRU histLRUpick Proxy Conns: 44 proxies, 50MB each
25
Cumulative Load balancing: Max/Min
26
Load balancing: Conclusions histLRUpick performs the best as number of proxies decrease, individual load increases Room for improvement: –RWFQ –replication
27
Roadmap Survey Summary Architecture: Detailed system architecture Analysis: Architecture analysis and results Comparison with other designs Conclusion and future direction
28
Comparison to Other Proxy Caches Internet www P P Document Characteristics –fragment, distribute video –keep initial portions of video Caching Approach –other approaches optimized for small documents high reference locality Proxy architecture –Distributed vs. centralized
29
Conclusion Caching in general is a good idea: –High hit rates for relatively small cache size HistLRUk –high hit rates –effective dynamic and cumulative load balancing Used Jigsaw, HTTP/1.1, GET/PUTs to build prototype storage proxy server
30
Future Work Other load balancing schemes Fault Tolerance FF/REW support Security/Authentication Proxy Cluster Cooperation
31
histLRUpick Dynamic Load Balancing Performance: 22 * 100 LRU reduce the number of proxies raise the cache size of each proxy to keep the same global cache size
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.