1. + Network Level Footprints of Facebook Applications Komal Pal Gautam Bhawsar

2. + Motivation Online social networks have become hugely popular Over 0.5B users But little information available on network impact of these OSNs Our area of interest – impact of third party applications on the OSN/Internet Over 81,000 apps on Facebook alone #Apps growing at an unbounded rate because of opening up of the developer platform by major OSNs Spiral growth in traffic due to open APIs Facebook – 30%, Twitter – 20X

3. + Motivation Our OSN of choice- Facebook 150M monthly active users (MAU) Hope to provide guidelines to OSNs and application developers for managing traffic growth Very critical to understand the kind of infrastructure required by the OSN as well as Application to support the spiral growth.

4. + Facebook and 3 rd party applications Typical OSN Framework

5. + Limitations OSN platform Treated as Black Box Lack of access to proprietary information and internal design details

6. + Our contributions Detailed measurement methodology Characterization of delays involved in user-3 rd party interactions through Facebook.

7. + Our model Performance metric – End to end delay perceived by users. Depends on – Geographical distribution of users and their access speeds Processing speed and overhead of OSNs Bandwidth and processing speeds of Application servers

8. + Our model Questions that we need answers to- Do overheads incurred by Facebook and Application constitute a significant portion of end-to-end delay? Do external developers of popular and viral applications need exorbitantly high resources to serve content to users? What are the possible provisioning strategies at OSNs like Facebook? Does Facebook segregate data according to user characteristics such as country, network or number of friends? Does it provision resources differently for 3 rd party applications, or differentiate user requests based on properties such as geographical locations?

9. + Defining the delays App server Request Queuing delay (d q ) App server Request Processing Delay (d p ) OSN server Request Forwarding Delay (d f ) OSN server Response Processing Delay (d g )

10. + Defining the delays Sequence of interactions between Client-OSN-Application

11. + Approach Developed and launched 6 FB applications in use by millions of users monthly- Hugged, iSmile, MyAngels, Holiday Cheers (greetings based) Pound Puppies The Streets

12. + Approach Our applications vs other popular applications on Facebook Application semantics : Hugged, iSmile, My Angels and Holiday Cheers are similar to 61% of the top 200 applications Delay requirements : 70% of top 200 apps utilize Facebook canvas design Engagement ratio: Hugged, iSmile and Holiday Cheers are similar to 31.6% of the top 200 apps. Applications represent a diverse mix and are representative of top 200 applications

13. + Passive Measurements (at App server) Requests received from Facebook server- Page View (PV) Not Installed (NI) Inline requests (IR) PV requests constitute the major workload

14. + Experiment (Active measurements) Planet Lab nodes send active probes to app server through the OSN 2xPL nodes across 32 countries 3 Facebook user accounts- X(39 friends), Y(4 friends), Z(208 friends) Used the 3 user accounts to access the 6 applications

15. + Experiment (Active measurements) Measurements based on 4 experiments- Client sends HTTP GET request to OSN. Time of departure (T dep ) and request size (S client-req ) are logged App server receives request. Logs arrival time stamp App server sends response, arrival and departure time stamps and response size Client receives response. Logs time stamp of arrival (T arr ) and response size (S osn-resp )

16. + Results

17. + Measuring d f and d g d f : Request size (S client-req ) was varied from 0 to 50Kb d g : Response size (S OSN-resp ) was varied. Types of response : User related (FBML name, profile picture, status tags) Non-user related (random HTML/JavaScript or non-user specific FBML tags) Round trip delays used for measurement after eliminating propagation and transmission delays.

18. + Results (Application server delays) Server loads follow diurnal pattern and show different growth patterns based on popularity and seasonal nature of application. Already popular applications attract more new users- exhibiting preferential attachment phenomena

19. + Results (Application server delays)

20. + Results (Application Server delays) Queuing delay is negligible, while processing delays correlate positively with loads and are affected by resource provisioning. d q < 20ms on average

21. + Request response sizes remain stable across time, independent of load. Average response sizes remain stable for the entire measurement period. Smallest response size observed for the least popular application, The Streets (1.5-3 KB) Largest response size observed for the most popular application, Hugged (4-5 KB) Results (Application Server delays)

22. + The type of interactions (i.e. API calls) from third party application servers to OSNs affect application server delays, impacting the overall user experience. Results (Application Server delays)

23. + Estimating d f and d g Analysis of RT delays from PL nodes to Facebook servers in California Avg. RTT was 170ms Experiments from nodes in different countries showed similar d f and d g values.

24. + Results (OSN delays) OSN Request Forwarding delays (d f ) are around 130ms for user requests of size 0-1 Kb (typical for the 6 chosen Facebook applications) Per application d f increases linearly with increase in request size. Per application d f does not vary with load (request arrival rate)

25. + Results (OSN delays) Processing HTML takes less time compared to processing Java Script d g (HTML) = 0.01 ms/byte, d g (Javascript)= 0.04 ms/byte d g for FBML content targeting non-user entities is unaffected by the target’s popularity. It also remains consistent with time. d g ~ 310 ms for 250 FBML network tags, regardless of the network’s popularity, but no change with time. FBML user tag processing delays do not vary with target users’ popularity and network membership. d g is similar (avg. difference of <15ms) across different ranges of FB friends for the various FBML tags.

26. + Results (OSN delays) FBML user tag processing times vary with type of FBML tag. FBML profile picture tags take the longest, whereas the FBML user status tags take the shortest times. Data caching has significant effect on FBML tag processing delays.

27. + Results (OSN delays) d g increases linearly with the number of FBML tags. The increased delays show no appreciable variation across third- party applications and target user characteristics. suggests lack of parallel processing of FBML tags with individual requests

28. + Results (OSN delays) d g varies with time of day but is not consistent with application usage (load). d g is a significant chunk of total time per user request to third party applications, for both realistic average workloads and hypothetical scenarios with varying size of content. The Streets : d g = 44.4% of 1.30s total time Hugged : d g = 68.8% of 2.21s total time Pound Puppies : d g = 59.9% of 1.77s total time

29. + Conclusions Q: Do overheads incurred by Facebook and Application constitute a significant portion of end-to-end delay? A: Yes, delays across OSNs can dominate the overall latency experienced by users interacting with 3 rd party applications.

30. + Conclusions Q: Do external developers of popular and viral applications need exorbitantly high resources to serve content to users? A : One does not need exorbitant resources to launch and maintain an extremely popular OSN application, despite its viral growth or seasonal fluctuations. Processing requirements may vary on a per-application basis but these are not very high.

31. + Conclusions Q: What are the possible provisioning strategies at OSNs like Facebook? Does Facebook segregate data according to user characteristics such as country, network or number of friends? Does it provision resources differently for 3 rd party applications, or differentiate user requests based on properties such as geographical locations? A: Facebook is well provisioned, even for viral applications. Impact due to geographical location of users can be mitigated by moving data centers and application servers closer to users and/or avoiding frequent setup/teardown of HTTP connections.

32. + Conclusions For the Application developer Provision for diurnal and seasonal fluctuations Limit the FBML tags Queue API calls during high activity For the OSN Move DCs closer to the users to minimize RTTs Use persistent HTTP connections, where RT propagation delays are high Parallelize FBML tag processing * Technical accuracy of the paper has been verified by high ranked members of the Facebook development team.

33. + Thank You!