Transcript No Slide Title

MiddleMan: A Video Caching Proxy
Server
Soam Acharya
Inktomi Corporation
Foster City, CA
Brian Smith
Department of Computer Science
Cornell University
Ithaca, NY
NOSSDAV 2000
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
Problems With VOW
Internet
ISP
28.8/56 Kbps
CNN
T1
• 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
Our Goals
• Low end, low cost approach
• Scalable
• Utilize highly connected network of
powerful commodity PCs
How Does It Work?
P
TCP
CNN
Coordinator
P
Video web caching proxy system
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
Roadmap
•
•
•
•
•
Survey Summary
Architecture: Detailed system architecture
Analysis: Architecture analysis and results
Comparison with other designs
Conclusion and future direction
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
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 …
Roadmap
•
•
•
•
•
Survey Summary
Architecture: Detailed system architecture
Analysis: Architecture analysis and results
Comparison with other designs
Conclusion and future direction
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
How It Works I
WWW
C
Coordinator
P
Proxy
C
P
P
P
How It Works II
WWW
C
Coordinator
P
Proxy
C
P
P
P
MiddleMan: Actual Architecture
WWW
LAN
LP
LP
Local Proxy
Storage Proxy
Communication
Data transfer
LP
LP
Coordinator
SP
C
SP
C
SP
Linking Multiple Proxy Clusters
C
C
C
Roadmap
•
•
•
•
•
Survey Summary
Architecture: Detailed system architecture
Analysis: Architecture analysis and results
Comparison with other designs
Conclusion and future direction
Issues To Analyze
•
•
•
•
Local cache size
Size of file blocks
Caching algorithm
Controlling proxy load
Performance Analysis (via
Simulations)
• Caching
– analyze byte hit rates of various caching
algorithms
• Load Balancing
– load analysis on the proxies
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
Overall Cdt Cache Performance
50 MB, 8.6%
90%
25 MB, 4.3%
80%
70%
12 MB, 2.1%
Byte Hit Rate
60%
50%
40%
30%
20%
10%
0%
LRU-3
FIFO
LFU
LRU
Perfect
LRU-3
FIFO
LFU
LRU
Perfect
LRU-3
FIFO
LFU
LRU
Perfect
Caching Conclusion
• Not much difference in caching
algorithm performance
– cannot evaluate architecture solely based
on byte hit rate
– Should consider load balancing behavior
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
Measuring
Dynamic Load
Balancing
Performance
# of connections
P1
P2
P3
Example Proxy
Connection Plot
# of connections
# of connections
Total # of
connections
Time
connections
at (max)
proxy
Time
Proxy
Conns:
44
proxies,
50MB
each
LRU
histLRUpick
Cumulative Load balancing:
Max/Min
16000.00
14000.00
Max
Min
12000.00
MBytes
10000.00
8000.00
6000.00
4000.00
2000.00
0.00
11-HistLRUpick
11-LRU
22-HistLRUpick
22-LRU
44-HistLRUpick
44-LRU
Load balancing: Conclusions
• histLRUpick performs the best
• as number of proxies decrease,
individual load increases
• Room for improvement:
– RWFQ
– replication
Roadmap
•
•
•
•
•
Survey Summary
Architecture: Detailed system architecture
Analysis: Architecture analysis and results
Comparison with other designs
Conclusion and future direction
Comparison to Other Proxy Caches
• Document Characteristics
– fragment, distribute video
– keep initial portions of video
• Caching Approach
– other approaches optimized for
• small documents
• high reference locality
www
• Proxy architecture
– Distributed vs. centralized
Internet
P
P
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
Future Work
•
•
•
•
•
Other load balancing schemes
Fault Tolerance
FF/REW support
Security/Authentication
Proxy Cluster Cooperation
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
histLRUpick