-
Notifications
You must be signed in to change notification settings - Fork 44
Update h2 windowing algo & Http Client benchmark #388
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
This pull request introduces 1 alert when merging 4cd7338 into f81ee94 - view on LGTM.com new alerts:
|
This pull request introduces 1 alert when merging f445de0 into f81ee94 - view on LGTM.com new alerts:
|
This pull request introduces 1 alert when merging f86a9f7 into f81ee94 - view on LGTM.com new alerts:
|
This pull request introduces 1 alert when merging ca0c7c5 into f81ee94 - view on LGTM.com new alerts:
|
source/h2_connection.c
Outdated
@@ -1762,6 +1767,8 @@ static void s_handler_installed(struct aws_channel_handler *handler, struct aws_ | |||
aws_linked_list_push_back( | |||
&connection->thread_data.outgoing_frames_queue, &connection_window_update_frame->node); | |||
connection->thread_data.window_size_self += initial_window_update_size; | |||
/* For automatic window management, we only update connectio windows when it droped blow 50% of MAX. */ | |||
connection->thread_data.window_size_self_dropped_threshold = AWS_H2_WINDOW_UPDATE_MAX / 2; |
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.
nit: pull this magic number into a constant?
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.
it's derive from a constant... and it's more clear about where it comes from/
@@ -408,12 +408,6 @@ static int s_localhost_integ_h2_upload_stress(struct aws_allocator *allocator, v | |||
s_tester.alloc = allocator; | |||
|
|||
size_t length = 2500000000UL; | |||
#ifdef AWS_OS_LINUX |
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.
remove this, since it seems to be the flow control window issue.
- we sent out too much
- the initial window from the local server is small (default to the magic 65535). https://httpwg.org/specs/rfc7540.html#iana-settings
- The local server code also update the window as data received.
Don't know why it matters that much for linux comparing to the other platform. (I think we do found this windowing issue affect linux more as well from the canary before, which matches this)
* drops below the threshold. | ||
* Default to half of the initial connection flow-control window size, which is 32767. | ||
*/ | ||
uint32_t conn_window_size_threshold_to_send_update; |
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.
extremely debatable: you could just leave these out of the public options, until someone actually asks for it
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 keep it. It makes the documentation easier to explain the behavior.😉
* The client will send the WINDOW_UPDATE frame to the server only valid. | ||
* If the pending_window_update_size is too large, we will leave the excess to send it out later. | ||
*/ | ||
uint64_t pending_window_update_size_thread; |
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.
utterly trivial. It's already in a struct named thread_data
, no need to repeat
uint64_t pending_window_update_size_thread; | |
uint64_t pending_window_update_size; |
or
uint64_t pending_window_update_size_thread; | |
uint64_t pending_window_update_size_self; |
@@ -150,7 +165,7 @@ struct aws_h2_connection { | |||
bool is_cross_thread_work_task_scheduled; | |||
|
|||
/* The window_update value for `thread_data.window_size_self` that haven't applied yet */ | |||
size_t window_update_size; | |||
uint64_t pending_window_update_size_sync; |
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.
trivial: it's already in synced_data.
uint64_t pending_window_update_size_sync; | |
uint64_t pending_window_update_size; |
or
uint64_t pending_window_update_size_sync; | |
uint64_t pending_window_update_size_self; |
@@ -150,7 +165,7 @@ struct aws_h2_connection { | |||
bool is_cross_thread_work_task_scheduled; | |||
|
|||
/* The window_update value for `thread_data.window_size_self` that haven't applied yet */ |
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.
/* The window_update value for `thread_data.window_size_self` that haven't applied yet */ | |
/* Value for `thread_data.pending_window_update_size` that we haven't applied yet */ |
include/aws/http/private/h2_stream.h
Outdated
* The client will send the WINDOW_UPDATE frame to the server only valid. | ||
* If the pending_window_update_size is too large, we will leave the excess to send it out later. | ||
**/ | ||
uint64_t pending_window_update_size_thread; |
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.
thread
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.
all my feedback was style stuff. Looks good overall
AWS_BUILD_CANARY=ON
cmake flagcd build/bin/canary && ./canary
ISSUE FOUND & FIXED
We update the window for connection for each data frame received, which really slows us down for frequent small chunk of data frames receiving.
Providing tiny increments to flow control in WINDOW_UPDATE frames can cause a sender to generate a large number of DATA frames. from here
h2: respect the initial window size setting #514
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.