Help trying to understand Chrome NetLog

[Yahya Khatib]

I'm trying to time page rendering times using different network settings. For that I am looking at the NetLog created by Chrome (using the --log-net-log flag with --net-log-level=0). However, I'm having trouble understanding the created JSON log; it's mainly to do with matching event types. Take for example this event:

{"params":{"delta":-871,"stream_id":3,"window_size":10484889},"phase":0,"source":{"id":78,"type":1},"time":"1292588413","type":163},

According to net/base/net_log_event_type_list.h, no event type has such parameters. What am I missing here?

[Joao da Silva]

You're missing chrome://net-internals/.

1. Go to chrome://net-internals/ and notice the red bar on top. It's capturing net events.

2. Do your stuff

3. Click the stop button on the red bar.

4. Click "Events" on the left, look at the captured events.

That said, the Timeline in the Developer Tools is probably a better way to measure page rendering times.

- Joao

--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

[Yahya Khatib]

Thanks for your reply, Joao.

I am aware of these tools, but the reason I am looking at the logs is that I want to make a script to automate such benchmarks for a long list of websites using different network stack parameters. Doing it manually using net-internals or Timeline is too tedious for my purposes.

/Yehia

[Joao da Silva]

On Mon, Nov 5, 2012 at 5:17 PM, Yahya Khatib <yehia.e...@gmail.com> wrote:

Thanks for your reply, Joao.

I am aware of these tools, but the reason I am looking at the logs is that I want to make a script to automate such benchmarks for a long list of websites using different network stack parameters. Doing it manually using net-internals or Timeline is too tedious for my purposes.

You can use net-internals to check what event that was. You can also see that that event has type 163, and the 164th entry in net/base/net_log_event_type_list.h is SPDY_STREAM_UPDATE_SEND_WINDOW. That event is generated from NetLogSpdyStreamWindowUpdateCallback at net/spdy/spdy_stream.cc.

- Joao

[Yehia]

Exactly. But the enum in the header file defines this event having these additional parameters:

// This event indicates that the send window has been updated

//   {

//     "id":         <The stream id>,

//     "delta":      <The window size delta>,

//     "new_window": <The new window size>,

//   }

EVENT_TYPE(SPDY_STREAM_UPDATE_SEND_WINDOW)

... which is different from the ones in the log (see my first post). This is where I am confused. Are these parameters optional? I don't understand?

/Yehia

--
/Yehia

[Joao da Silva]

That comment is outdated, see the code for the "real" parameters.

[Yehia]

So, the enum in the header is not binding and the implementation of the individual modules (such as SpdyStream) can define their own parameters. Is that correct? In that case, it will be difficult to lookup the parameters of each event as they have to be tracked down individually.

/Yehia

--
/Yehia

[Chris Bentzel]

+mmenke,eroman

Note that the NetLog content is intentionally not stable, and may change at any time. There is an effort (or at least desire) to remove some dependencies such as LoadTimingObserver and DevToolsNetLogObserver on it.

[Yehia]

Thanks for the responses, Chris and Matt. It is indeed difficult to automate such tests without changing the browser internals on particular events.

I'll look further into HAR-based options.

/Yehia

On Mon, Nov 12, 2012 at 4:08 PM, Matt Menke <mme...@chromium.org> wrote:

As Chris said, we want to get away from having Chrome code depend on net-internals.  Depending on specific SPDY even parameters just sounds like a bad idea to me.  As you can tell by the outdated comment, individual event parameters do sometimes change.  If you just depend on URL_REQUEST start/stop times, and getting the names from those, that has been fairly stable across versions, but may result in code that will be broken by future refactoring.

Also, using --log-net-log=filename has performance implications, since it's writing to files on the IO thread - it doesn't use another thread to make sure it can get both startup and shutdown events, though suppose we could just block out own thread on quit, to get the same behavior.

For performance measurement, have you considered using HAR files?  They use a stable, browser-independent format.

To manually generate them, open up dev-tools and go to the network tab.  Navigate to a page, right click somewhere on on the list of loaded resources, and select "save all entries as HAR".  You can also record multiple page loads by clicking on the record icon.  I'm not sure how to automate generation of these files, though http://www.webpagetest.org manages to do so.

--
/Yehia