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

  • Upload
    vic

  • View
    26

  • Download
    2

Embed Size (px)

DESCRIPTION

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 - PowerPoint PPT Presentation

Citation preview

PowerPoint Presentation

Timecard:Controlling User-Perceived Delays in Server-Based Mobile ApplicationsLenin Ravindranath, Jitu Padhye, Ratul Mahajan, Hari Balakrishnan1

CloudServices

MobileApps2

CloudServices

Users are impatient100ms delay can cost substantial drop in revenue at AmazonSimilar observations from Google and Bing

Response Time Matters3Control Variability in Response TimesRequestResponseFixed deadlinesTrade-off quality for response timeMore time to compute, better quality resultsFlexible Services

DeadlineServer processing4The elephant is outside the roomRequestResponseServer processingThe elephant is outside the room

User clickServer processingAppAppServerRequestResponseReading sensorsRadio State(Radio wakeup)DNS and TCP connectLink quality(3G, HSPA+, LTE, Wifi)TCP stateDatasizePhone modelParsing andRendering

UplinkDownlinkPhone modelUser perceived delayHighly variable6No visibility into delays outside the service

User clickServer processingAppAppServerRequestResponseReading sensorsRadio State(Radio wakeup)DNS and TCP connectLink quality(3G, HSPA+, LTE, Wifi)TCP stateDatasizePhone modelParsing andRendering

UplinkDownlinkPhone modelUser perceived delayHighly variableUnaware of end-to-end delaysClients with non-trivial external delaysPoor end-to-end response timesClient with minimal external delaysDo not produce the best quality result

Could adapt differently for different users7TimecardGetElapsedTime();PredictDownstreamTime(responseSize);

Time elapsed since user requestPredicted downlink + app processing delayAppAppServer8Timecard

AppAppServerDesired end-to-end delayAppGetElapsedTime();PredictDownstreamTime(responseSize);Adapt Processing Time9Timecard

AppServerDesired end-to-end delayAppAppGetElapsedTime();PredictDownstreamTime(responseSize);Adapt Response10Timecard

AppServerDesired end-to-end delayAppGetElapsedTime();PredictDownstreamTime(responseSize);11TimecardGetElapsedTime();PredictDownstreamDelay(responseSize);AppAppServer12

UI ThreadBackground ThreadBackground ThreadServer ThreadsUI dispatcherThread startGPS startWeb requestGPS callbackEvent handlerSpawn workersRequest handlerSend responseWeb callbackAppAppServerChallenges13

UI ThreadBackground ThreadBackground ThreadAppAppServerChallengesTransactionGetElapsedTime();PredictDownstreamDelay(responseSize);

No single reference clockAutomatically collect data and learn14Online Transaction TrackingTime SynchronizationDownstream Delay PredictorDownlink delayApp processing delayTimecard15

UI ThreadBackground ThreadBackground ThreadServer ThreadsAppAppServerTransaction TrackingTCTransaction Context- Timestamps, transaction/device/network informationTCTCTCTCTCTCTCTCGetTransaction().GetStartTime();16Periodic time sync probes from app to serverFind drift and offset between clocksUse server clock as reference clockClient maps local time to server time

Synchronizing TimeEfficient technique for probingAware of the radio state and trafficMinimal extra delaysEnergy efficient

17Predicting Downstream Time

AppAppServerDownlink timeApp processing timePredictDownstreamTime(responseSize);18Predicting Downlink Time

Data size1 KB to 40 KB of dataRTT matters than throughputPredict RTT

TCP window state mattersMultiple RTTsEstimate TCP Window & number of RTTs

Complicated by middleboxes

MiddleboxRead TCP stateEstimateTCP state19Predicting Downlink Time

Data sizeModel downlink delayRecent RTTBytes already transferredResponse sizeNetwork providerClient OS

MiddleboxEstimateTCP stateError in cellular networkmedian 17 ms90th percentile 86ms20Predicting App Processing Time

Parsing and rendering depends on data sizeModel processing time as a function ofResponse data sizePhone model4.6% (8ms) median error, 10% in 90th percentile21Timecard ImplementationAppAppServerTransaction TrackingTransaction TrackingLoggingPredictorTime SyncData CollectionAutomatic InstrumentationWP AppsASP .NET servicesAPIs22

Timecard can help control end-to-end delayModified two services (and two apps) to use timecardMobile Ads Service230.1% runtime overhead

Less than 1% memory overheadGarbage collection in idle time

Less than 1% network overhead

Negligible battery overheadTimecard Overhead24TimecardGetElapsedTime();PredictDownstreamDelay(responseSize);

AppAppServerAdapt Processing TimeAdapt ResponseDesired end-to-end delay25Apply Timecard to TimecardSOSP DeadlineGetElapsedTime();Adapt quality and scope of the paperPredictDownstreamTime(scope);

26