search

catapult-project / catapult

Deprecated Catapult GitHub. Please instead use http://crbug.com "Speed>Benchmarks" component for bugs and https://chromium.googlesource.com/catapult for downloading and editing source code..
https://chromium.googlesource.com/catapult
BSD 3-Clause "New" or "Revised" License
1.93k stars 564 forks source link

Figure out how ResourceFetcher::requestresource relates to DevTools initiators #1723

Closed natduca closed 8 years ago

natduca commented 9 years ago

Devtools has network initiator traces. We also have ResourceFetcher::requestresource traces. Lets figure out what they are and have one principled solution.

@caseq @chiniforooshan

chiniforooshan commented 9 years ago

Looks like network initiator trace events (in CrRendererMain) have byte counts and network durations. However, caching information is not logged in traces, devtools get's it from inspectors (?). So, we can move forward by either:

1- log mem/disk caching information in traces (where devtools inspectors send this information) and ignore the NetLog, or

2- link resource requests to NetLog slices. NetLog is the truth source and has all the information.

1 looks easier and is more similar to devtools. WDYT?

natduca commented 9 years ago

Recapping our VC yesterday, my recommendation is to go with 2. The devtools data are definitely easier to get to, but they have custom plumbing that enables them to get this data. With approach 1, as we start wanting deeper and deeper understanding of the netstack, we'll start having to do more and more plumbing down to devtools. I'd like to avoid that if possible.

Maybe the next step is to investigate the complexity of 2, but then if it starts looking really really hard, we go with 1 for a temporary stopgap.

benshayden commented 8 years ago

@chiniforooshan Any update?

chiniforooshan commented 8 years ago

Please see the last comment on #1725. Will create new issues for Net Instrumentation V2.