-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix a bunch of HTTP measurement and handling issues #1047
Conversation
Benchmarks comparing this branch and master with the same test script from #794 (comment): This PR:
The slightly better results for the code of this PR are probably a fluke, since I'm not doing anything that could speed the process up. Quite the opposite, these fixes add 2 mutex operations for each HTTP request... But it probably means that there aren't any huge performance regressions with the new code. |
Codecov Report
@@ Coverage Diff @@
## master #1047 +/- ##
==========================================
+ Coverage 72.64% 72.81% +0.17%
==========================================
Files 133 133
Lines 9848 9882 +34
==========================================
+ Hits 7154 7196 +42
+ Misses 2276 2270 -6
+ Partials 418 416 -2
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #1047 +/- ##
==========================================
+ Coverage 72.67% 72.79% +0.11%
==========================================
Files 133 133
Lines 9846 9878 +32
==========================================
+ Hits 7156 7191 +35
+ Misses 2274 2271 -3
Partials 416 416
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems pretty good. I don't see any reason why this should be buggy (apart from some magical transport reuse that we are not aware in the stdlib).
Can you add the benchmark as well, as a benchmark :) possibly hitting the local httpbin .
It's going to be a bit tricky to do, but I'll see if I can't work it in. The Go benchmarking logic should hopefully somewhat compensate for the lack of the multiple VUs and no k6 scheduling, though I'm not sure about the buffer pools. It think that benchmark will probably return more reliable results, but they won't be as realistic as the ones from the full end-to-end test. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Can you put the benchcmp results from before to now in the commit message when you merge? Maybe in the PR as well
Not ideal, but... https://twitter.com/CodeWisdom/status/1136250570455605249
|
This should fix #1041, fix #1044, fix #925, and also fix a potential minor data race in the
httpext.Tracer
! Hopefully, without introducing new bugs or performance regressions...While investigating this, I realized that we should up the priority of fixing the HTTP digest authentication: #800