tcnksm / go-httpstat

Tracing golang HTTP request latency
MIT License
421 stars 72 forks source link

result.ContentTransfer freezed value since update Go1.8 #13

Open bennneuh opened 7 years ago

bennneuh commented 7 years ago

Hello,

Thanks again for the update in 1.8

I have a small issue since the update. I'm not sure it's linked to the update, but i don't understand.

i always have the same fix value for ContentTransfert:

with:

end := time.Now()
fmt.Println("result.ContentTransfer(end) ", result.ContentTransfer(end))

The result is always: result.ContentTransfer(end) 2562047h47m16.854775807s

Thanks for your help,

Benoît

bennneuh commented 7 years ago

FYI i have tested in the example "_example" by adding: ` end := time.Now()

log.Printf("YO Name Lookup:    %d ms", int(result.NameLookup/time.Millisecond))
log.Printf("YO Connect:        %d ms", int(result.Connect/time.Millisecond))
log.Printf("YO Start Transfer: %d ms", int(result.StartTransfer/time.Millisecond))
log.Printf("YO Total:          %d ms", int(result.Total(end)/time.Millisecond))`

i have the same issue.

But no issue with fmt.Printf("%+v\n", result)

bennneuh commented 7 years ago

For the moment i have fixed the issue like that:

`func (r *Result) ContentTransfer(t time.Time) time.Duration { //return t.Sub(r.t4) return r.contentTransfer }

// Total returns the duration of total http request. // It is from dns lookup start time to the given time. The // time must be time after read body (go-httpstat can not detect that time). func (r *Result) Total(t time.Time) time.Duration { //return t.Sub(r.t0) return r.total }`

But i'm sure it's not the best way :) because the "t" is useless and i need to run result.End(end) before.

yanc0 commented 7 years ago

On yanc0/beeping we locked this package on commit fae40520f4ba0a112874d1f0deb9498ebb2198cb before the regression.


[[dependencies]]
  name = "github.com/tcnksm/go-httpstat"
  revision = "fae40520f4ba0a112874d1f0deb9498ebb2198cb"
davinchia commented 7 years ago

Also facing this issue.

Its constantly returning 9223372036854 ms for me.

Printing out results gives me TLSHandshake: 193 ms, ServerProcessing: 100 ms, ContentTransfer: - ms, so seems to be not recording anything.

bennneuh commented 7 years ago

Up :)

tzdybal commented 6 years ago

I was googling for 2562047h47m16.854775807s and found this post (we also have a problem with dates ethereumproject/go-ethereum#366).

The root of the problem is: time difference is calculated against zero value of time.Time. This causes overflow intime.Sub, which causes returning maxDuration constant.

The value for this constant is exactly 2562047h47m16.854775807s or 9223372036854 or 1<<63 -1 (nanoseconds).

rif commented 6 years ago

Yes, looks like the variables t0-t4 are no longer populated but they are still used by ContentTransfer and Total methods, resulting the duration since zero time. But I only had this issue because I was using dep tool with the latest release, switching to master solved this issue.

anthonynsimon commented 6 years ago

I also found this issue when using dep, in my case it's resolving to the latest release (v0.2.0).

Probably adding a new release with the corresponding bump in the semver would fix this for other dep users?

johannesfritsch commented 6 years ago

Same problem here. Fixed at some older revision for now.

vincentvdk commented 4 years ago

using go get github.com/tcnksm/go-httpstat@master fixed it for me.

teja42 commented 2 years ago

using go get github.com/tcnksm/go-httpstat@master fixed it for me.

Yep this worked for me. I'm using go v1.17