1 / 26

Timecard : Controlling User-Perceived Delays in Server-Based Mobile Applications

Timecard : Controlling User-Perceived Delays in Server-Based Mobile Applications. Lenin Ravindranath, Jitu Padhye, Ratul Mahajan, Hari Balakrishnan. Cloud Services. Mobile Apps. Response Time Matters. Cloud Services. Users are impatient

vic
Download Presentation

Timecard : Controlling User-Perceived Delays in Server-Based Mobile Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Timecard:Controlling User-Perceived Delays in Server-Based Mobile Applications Lenin Ravindranath, Jitu Padhye, Ratul Mahajan, Hari Balakrishnan

  2. Cloud Services Mobile Apps

  3. Response Time Matters Cloud Services • Users are impatient • 100ms delay can cost substantial drop in revenue at Amazon • Similar observations from Google and Bing

  4. Control Variability in Response Times Deadline • Fixed deadlines • Trade-off quality for response time • More time to compute, better quality results • Flexible Services Server processing Request Response

  5. The elephant is outside the room Server processing Request Response

  6. The elephant is outside the room Server processing Request Response Server TCP state Phone model Uplink Downlink Phone model Reading sensors Datasize Link quality (3G, HSPA+, LTE, Wifi) App App DNS and TCP connect User click Parsing and Rendering Radio State (Radio wakeup) Highly variable User perceived delay

  7. No visibility into delays outside the service • Unaware of end-to-end delays • Clients with non-trivial external delays • Poor end-to-end response times • Client with minimal external delays • Do not produce the best quality result • Could adapt differently for different users Server processing Request Response Server TCP state Phone model Uplink Downlink Phone model Reading sensors Datasize Link quality (3G, HSPA+, LTE, Wifi) App App DNS and TCP connect User click Parsing and Rendering Radio State (Radio wakeup) Highly variable User perceived delay

  8. Timecard PredictDownstreamTime (responseSize); GetElapsedTime(); Server App App Predicted downlink + app processing delay Time elapsed since user request

  9. Timecard PredictDownstreamTime (responseSize); GetElapsedTime(); Adapt Processing Time Server App App App Desired end-to-end delay

  10. Timecard PredictDownstreamTime (responseSize); GetElapsedTime(); Server Adapt Response App App App Desired end-to-end delay

  11. Timecard PredictDownstreamTime (responseSize); GetElapsedTime(); Server App App Desired end-to-end delay

  12. Timecard PredictDownstreamDelay (responseSize); GetElapsedTime(); Server App App

  13. Challenges Send response Spawn workers Request handler Server Threads Server App App Background Thread GPS callback Web request Web callback Background Thread UI dispatcher GPS start Event handler UI Thread Thread start

  14. Challenges GetElapsedTime(); PredictDownstreamDelay (responseSize); No single reference clock Automatically collect data and learn Server App App Background Thread Background Thread UI Thread Transaction

  15. Timecard • Online Transaction Tracking • Time Synchronization • Downstream Delay Predictor • Downlink delay • App processing delay

  16. Transaction Tracking GetTransaction(). GetStartTime(); TC TC Server Threads Server TC App App TC Background Thread TC Background Thread TC TC UI Thread TC Transaction Context TC - Timestamps, transaction/device/network information

  17. Synchronizing Time • Periodic time sync probes from app to server • Find drift and offset between clocks • Use server clock as reference clock • Client maps local time to server time • Efficient technique for probing • Aware of the radio state and traffic • Minimal extra delays • Energy efficient

  18. Predicting Downstream Time PredictDownstreamTime (responseSize); • Downlink time • App processing time Server App App

  19. Predicting Downlink Time Read TCP state • 1 KB to 40 KB of data • RTT matters than throughput • Predict RTT • TCP window state matters • Multiple RTTs • Estimate TCP Window & number of RTTs • Complicated by middleboxes Data size Middlebox Estimate TCP state

  20. Predicting Downlink Time • Model downlink delay • Recent RTT • Bytes already transferred • Response size • Network provider • Client OS Data size Middlebox Estimate TCP state • Error in cellular network • median 17 ms • 90th percentile 86ms

  21. Predicting App Processing Time • Parsing and rendering depends on data size • Model processing time as a function of • Response data size • Phone model 4.6% (8ms) median error, 10% in 90th percentile

  22. Timecard Implementation Data Collection Automatic Instrumentation • WP Apps • ASP .NET services APIs Predictor Server Transaction Tracking App App Logging Transaction Tracking Time Sync

  23. Timecard can help control end-to-end delay • Modified two services (and two apps) to use timecard Mobile Ads Service

  24. Timecard Overhead • 0.1% runtime overhead • Less than 1% memory overhead • Garbage collection in idle time • Less than 1% network overhead • Negligible battery overhead

  25. Timecard PredictDownstreamDelay (responseSize); GetElapsedTime(); Adapt Processing Time Server Adapt Response App App Desired end-to-end delay

  26. Apply Timecard to Timecard PredictDownstreamTime (scope); GetElapsedTime(); Adapt quality and scope of the paper SOSP Deadline

More Related