An analysis of Facebook photo caching

Abstract

This paper examines the workload of Facebook's photoserving stack and the effectiveness of the many layers of caching it employs. Facebook's image-management infrastructure is complex and geographically distributed. It includes browser caches on end-user systems, Edge Caches at~20 PoPs, an Origin Cache, and for some kinds of images, additional caching via Akamai. The underlying image storage layer is widely distributed, and includes multiple data centers.We instrumented every Facebook-controlled layer of the stack and sampled the resulting event stream to obtain traces covering over 77 million requests for more than 1 million unique photos. This permits us to study traffic patterns, cache access patterns, geolocation of clients and servers, and to explore correlation between properties of the content and accesses. Our results (1) quantify the overall traffic percentages served by different layers: 65.5% browser cache, 20.0% Edge Cache, 4.6% Origin Cache, and 9.9% Backend storage, (2) reveal that a significant portion of photo requests are routed to remote PoPs and data centers as a consequence both of load-balancing and peering policy, (3) demonstrate the potential performance benefits of coordinating Edge Caches and adopting S4LRU eviction algorithms at both Edge and Origin layers, and (4) show that the popularity of photos is highly dependent on content age and conditionally dependent on the social-networking metrics we considered.

Characterizing Load Imbalance in Real-World Networked Caches

“…Once the hot object is detected, its replica is stored by the frontend cache, which can then serve all traffic flowing through it, via its local copy of the item and without burden on other servers. Studies show that even small front-end caches can substantially alleviate skewed object-access workload [5,7].…”

“…Our traces, therefore, are focused on load imbalance after caches higher up in the hierarchy have already been applied [7]. Moreover, our earlier analysis showed that after a layer of front-end caches, the popularities of objects are no longer a significant factor in Tao's load-imbalance.…”

Framework for Analyzing Android I/O Stack Behavior: From Generating the Workload to Analyzing the Trace

“…We found that SQLite and its journal files are responsible for approximately 90% of the write I/Orequests in both Facebook and Twitter applications. The reason for such high number of write I/O requests to the local storage is because Facebook and Twitter cache the timeline records in their SQLite table, which is common approach in modern SNS applications to improve the processing speed and to reduce the latency for user requests [30]. We also found that resources (.dat and .xml) and executable files are responsible for about 60% of the read I/O requests.…”

Exploring the Use of Tags for Georeplicated Content Placement

“…where p global [c] is the proportion of views in country c. UGC providers typically rely on multiple layers of caches (within browsers, at Internet Points-of-Presence, within datacenters), in addition to their primary storage system [21]. In our model, we aggregate all these caches in one single layer located in each country, set to an LRU eviction policy.…”