-
Notifications
You must be signed in to change notification settings - Fork 866
Retain prioritization information for closed streams #1924
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
Conversation
|
To confirm, you succeeded in reproducing the issue and the issue when away with this change? Sounds fantastic to me. |
That's right, here's a run with master serving files off the disk that shows the issue before the fix: I then ran 10 times the test which runs 9 page loads, and none of those had an issue. |
kazuho
left a comment
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.
Read the PR and the approach looks fine to me.
I've left comments while reading the code. I do not think we need to address all the issues now, but please let me submit these so that it does not get lost.
lib/http2/connection.c
Outdated
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.
I think we can add break here?
lib/http2/connection.c
Outdated
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.
I believe this is an unrelated change.
include/h2o/http2_internal.h
Outdated
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.
How about renaming the variable to next_slot? IMO that is the purpose of this index.
It might also make sense to add a doc-comment to streams that states that it is a ring buffer with next insertion point being next_slot.
lib/http2/connection.c
Outdated
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.
I would appreciate it if you could use size_t because the values is used for indexing an array.
include/h2o/http2_internal.h
Outdated
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.
I notice that in get_parent_stream_id function of lib/http2/connection.c, we might refer to h2o_http2_stream_t::stream_id that is relative to the address of sched_node.
Considering that, it might make more sense to simply keep a pointer to h2o_http2_stream_t that has all the values disposed of with the exception being stream_id and _refs.scheduler, rather than retaining a pointer to sched_node as well as separately keeping stream_id.
Note however that we also agree that it's a bit of waste to retain h2o_http2_stream_t even after the stream is closed. FWIW, I think we could use something like 94536be to move just the scheduling node to a different location.
The way of adjusting this structure depends on if and how we might fix the issue.
in the ring buffer of old streams
state when a stream gets closed
cbd305e to
25702ce
Compare
`h2o_http2_scheduler_openref_t` , so that closed streams can expose their stream id as well
|
Thank you for writing |
|
Thank you for the changes. It seems like we are going to fix this issue properly :-) I would appreciate it if you could consider deweerdt#2. Thank you in advance. |
Use subtyping instead of adding a callback
|
@kazuho merged deweerdt#2, thanks! |
This PR adds logic that has H2O record the priority information of the last 10 streams that were closed.
This plays better with Chrome's chain of exclusive dependencies that might be re-ordered, because it makes it more likely that we'll find a stream in the even of a re-ordering. I've tested the code against https://github.com/pmeenan/http2priorities and that gave consistently good results in webpagetest (100 successive good runs).