New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 863354 link

Starred by 2 users
Status: Available
Owner: ----
Cc:
mastiz@chromium.org
ios-bugs@chromium.org
█ tschumann@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , iOS , Chrome , Mac
Pri: 2
Type: Feature



Sign in to add a comment

Measure commit latencies

Project Member Reported by tschumann@chromium.org, Jul 13 
AFAIK, we don't have UMA metrics measuring the latency of GetUpdates or Commit messages which would be a great base line for overall latencies.

Further, it would be great to have per-data type latency metrics measuring the time it takes from an actual data modification being made to this change being successfully committed to the sync server.

Comment 1 by treib@chromium.org, Jul 16

Labels: -Type-Bug OS-Android OS-Chrome OS-iOS OS-Linux OS-Mac OS-Windows Type-Feature
Status: Available (was: Untriaged)

Comment 2 by treib@chromium.org, Sep 27 

Looks like Syncer::DownloadAndApplyUpdates and Syncer::BuildAndPostCommits might be good places to measure GetUpdates and Commit timings, respectively.
Might be good to also go one level up and measure timings per SyncCycle (which might include GetUpdates and/or Commit). This could happen in Syncer::NormalSyncShare, ConfigureSyncShare, and PollSyncShare. Or alternatively, maybe measuring the time between SyncCycle's ctor and SendSyncCycleEndEventNotification is enough.
►

Sign in to add a comment