+

Network Level Footprints of Facebook ApplicationsKomal Pal

Gautam Bhawsar

+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

+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.

+Facebook and 3rd party applications

Typical OSN Framework

+Limitations

OSN platform Treated as Black Box Lack of access to proprietary information and internal

design details

+Our contributions

Detailed measurement methodology Characterization of delays involved in user-3rd party

interactions through Facebook.

+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

+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 3rd party applications, or differentiate user requests based on properties such as geographical locations?

+Defining the delays

App server Request Queuing delay (dq)

App server Request Processing Delay (dp)

OSN server Request Forwarding Delay (df)

OSN server Response Processing Delay (dg)

+Defining the delays

Sequence of interactions between Client-OSN-Application

+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

+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

+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

+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

+Experiment (Active measurements) Measurements based on 4 experiments-

Client sends HTTP GET request to OSN. Time of departure (Tdep) and request size (Sclient-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 (Tarr)

and response size (Sosn-resp)

+

Results

+Measuring df and dg

df : Request size (Sclient-req) was varied from 0 to 50Kb

dg : Response size (SOSN-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.

+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

+Results(Application server delays)

+Results(Application Server delays) Queuing delay is negligible, while processing delays

correlate positively with loads and are affected by resource provisioning. dq < 20ms on average

+

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)

+

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)

+Estimating df and dg

Analysis of RT delays from PL nodes to Facebook servers in California Avg. RTT was 170ms Experiments from nodes in different countries showed

similar df and dg values.

+Results(OSN delays) OSN Request Forwarding delays (df) are around 130ms for user

requests of size 0-1 Kb (typical for the 6 chosen Facebook applications)

Per application df increases linearly with increase in request size.

Per application df does not vary with load (request arrival rate)

+Results(OSN delays) Processing HTML takes less time compared to

processing Java Script dg (HTML) = 0.01 ms/byte, dg (Javascript)= 0.04 ms/byte

dg for FBML content targeting non-user entities is unaffected by the target’s popularity. It also remains consistent with time. dg ~ 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. dg is similar (avg. difference of <15ms) across different ranges of

FB friends for the various FBML tags.

+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.

+Results(OSN delays) dg 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

+Results(OSN delays) dg varies with time of day but is not consistent with application usage (load).

dg 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 : dg = 44.4% of 1.30s total time Hugged : dg = 68.8% of 2.21s total time Pound Puppies : dg = 59.9% of 1.77s total time

+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 3rd party applications.

+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.

+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 3rd 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.

+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.

+

Thank You!