2

I'm using browsermob with selenium to create a har file then trying to analyze the file. Looking in the file I'm getting timing like: 'startedDateTime': '2016-05-31T14:37:06.752-06:00' This is great and all but I'd like more precision, out to the microsecond if possible.

I can see in a har file from google chrome development tools that it's at least possible there.

Is there a setting in broswermob or selenium that I can set in order to get the extra precision or another way to capture this extra precision?

supakadoo
  • 53
  • 5
  • Why do you need precision out to the microsecond? – Scott Mikutsky Jun 08 '16 at 17:53
  • @ScottMikutsky, why do we at stack overflow care why anyone who asks a question here needs any of the many weird things they request sometimes? – Ryan Jun 08 '16 at 18:03
  • @ScottMikutsky it's not necessarily a need it's more of a nice to have. I say microsecond as an example of extending the precision past where it's at. The more precision that's possible the better, if I could go to nanosecond that'd be great too. Point being is there a way to acquire more precision than millisecond when generating a har file with browsermob? – supakadoo Jun 08 '16 at 18:15

1 Answers1

2

The HAR spec specifies the startedDateTime of the pages and entries objects as:

startedDateTime [string] - Date and time stamp of the request start (ISO 8601 - YYYY-MM-DDThh:mm:ss.sTZD).

The ss.s portion is a bit ambiguous, but the examples given in the spec go out only to thousandths of seconds. So BrowserMob Proxy only creates entries with thousandths, to avoid breaking HAR readers.

Precision greater than milliseconds is probably going to introduce a lot of additional noise into the timings. Differences in nanoseconds can be caused by all manner of things (such as CPU scheduling) unrelated to the "actual" performance of the HTTP request. Of course that happens with milliseconds as well, but the more precise you get, the less accurate the timings are.

Ultimately, what the startedDateTime really indicates is the time that the system clock reported to some CPU thread spawned by BMP that kicked off at some indeterminate time after the last packet of the HTTP request was received by the network interface, processed by the OS, processed by the JVM, and decoded by netty, which happens asynchronously without timing guarantees. It should only be taken as a "reasonably" close approximation. FWIW, that's the only guarantee Chrome can make, too.

Jason Hoetger
  • 5,650
  • 2
  • 13
  • 14