Controlling UserPerceived Delays in ServerBased Mobile Applications Lenin Ravindranath Jitu Padhye Ratul Mahajan Hari Balakrishnan Cloud Services Mobile Apps Cloud Services Users are impatient ID: 259412
Download Presentation The PPT/PDF document "Timecard" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Timecard:Controlling User-Perceived Delays in Server-Based Mobile Applications
Lenin Ravindranath, Jitu Padhye, Ratul Mahajan, Hari BalakrishnanSlide2
Cloud
Services
Mobile
AppsSlide3
Cloud
Services
Users are impatient
100ms delay can cost substantial drop in revenue at Amazon
Similar observations from Google and Bing
Response Time MattersSlide4
Control Variability in Response Times
Request
Response
Fixed deadlines
Trade-off quality for response time
More time to compute, better quality results
Flexible Services
Deadline
Server processingSlide5
The elephant is outside the room
Request
Response
Server processingSlide6
The elephant is outside the room
User
click
Server processing
App
App
Server
Request
Response
Reading sensors
Radio State
(Radio wakeup)
DNS and TCP connect
Link quality(3G, HSPA+, LTE
, Wifi)
TCP state
Datasize
Phone model
Parsing and
Rendering
Uplink
Downlink
Phone model
User perceived delay
Highly variableSlide7
No visibility into delays outside the service
User
click
Server processing
App
App
Server
Request
Response
Reading sensors
Radio State
(Radio wakeup)
DNS and TCP connect
Link quality
(3G, HSPA+, LTE, Wifi)
TCP state
Datasize
Phone model
Parsing and
Rendering
Uplink
Downlink
Phone model
User perceived delay
Highly variable
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 usersSlide8
Timecard
GetElapsedTime
();
PredictDownstreamTime
(
responseSize
);
Time elapsed since
u
ser request
Predicted downlink + app
processing delay
App
App
ServerSlide9
Timecard
App
App
Server
Desired end-to-end delay
App
GetElapsedTime
();
PredictDownstreamTime
(
responseSize
);
Adapt Processing TimeSlide10
Timecard
App
Server
Desired end-to-end delay
App
App
GetElapsedTime
();
PredictDownstreamTime
(
responseSize
);
Adapt ResponseSlide11
Timecard
App
Server
Desired end-to-end delay
App
GetElapsedTime
();
PredictDownstreamTime
(
responseSize
);Slide12
Timecard
GetElapsedTime
();
PredictDownstreamDelay
(
responseSize
);
App
App
ServerSlide13
UI Thread
Background Thread
Background Thread
Server Threads
UI dispatcher
Thread start
GPS start
Web request
GPS callback
Event handler
Spawn workers
Request handler
Send response
Web callback
App
App
Server
ChallengesSlide14
UI Thread
Background Thread
Background Thread
App
App
Server
Challenges
Transaction
GetElapsedTime
();
PredictDownstreamDelay
(
responseSize
);
No single reference
clock
Automatically
collect data and learnSlide15
Online Transaction TrackingTime SynchronizationDownstream Delay PredictorDownlink delayApp processing delay
TimecardSlide16
UI Thread
Background Thread
Background Thread
Server Threads
App
App
Server
Transaction Tracking
TC
Transaction Context
- Timestamps, transaction/device/network information
TC
TC
TC
TC
TC
TC
TC
TC
GetTransaction().
GetStartTime();Slide17
Periodic time sync probes from app to serverFind drift and offset between clocksUse server clock as reference clockClient maps local time to server time
Synchronizing Time
Efficient technique for probing
Aware of the radio state and traffic
Minimal extra delays
Energy efficientSlide18
Predicting Downstream Time
App
App
Server
Downlink time
App processing time
PredictDownstreamTime
(
responseSize
);Slide19
Predicting Downlink Time
Data size
1 KB to 40 KB of data
RTT matters than throughput
Predict RTT
TCP window state matters
Multiple RTTsEstimate TCP Window & number of RTTs
Complicated by middleboxesMiddlebox
Read TCP state
EstimateTCP stateSlide20
Predicting Downlink Time
Data size
Model downlink delay
Recent RTT
Bytes already transferred
Response size
Network provider
Client OS
MiddleboxEstimateTCP state
Error in cellular network
median
17 ms
90
th
percentile 86msSlide21
Predicting App Processing Time
Parsing and rendering depends on data size
Model
p
rocessing time as a function of
Response data sizePhone model
4.6% (8ms) median error, 10% in 90
th
percentileSlide22
Timecard Implementation
App
App
Server
Transaction
Tracking
Transaction
Tracking
Logging
Predictor
Time Sync
Data Collection
Automatic Instrumentation
WP Apps
ASP .NET services
APIsSlide23
Timecard can help control end-to-end delay
Modified two services (and two apps) to use timecard
Mobile Ads ServiceSlide24
0.1% runtime overheadLess than 1% memory overheadGarbage collection in idle time
Less than
1%
network overheadNegligible battery overhead
Timecard OverheadSlide25
Timecard
GetElapsedTime
();
PredictDownstreamDelay
(
responseSize
);
App
App
Server
Adapt Processing Time
Adapt Response
Desired end-to-end delaySlide26
Apply Timecard to Timecard
SOSP
Deadline
GetElapsedTime
();
Adapt quality and scope of the paper
PredictDownstreamTime
(
scope
);