-
Notifications
You must be signed in to change notification settings - Fork 2.6k
make the ws buffer size configurable #10013
Conversation
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 (modulo missing docs, and refinement), we are far beyond the "don't add any RPC-related CLI options" point anyway, and config files are nowhere around the corner, so I'm okay with adding it, especially that it addresses a particular pain point you are having.
client/cli/src/commands/run_cmd.rs
Outdated
/// Set the the maximum RPC output buffer size. Default is 10MiB. | ||
#[structopt(long = "rpc-max-in-buffer-capacity")] | ||
pub ws_max_in_buffer_capacity: Option<usize>, |
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.
Is there a use case for in buffer? We already have max_rpc_payload
which limits that, no?
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.
Not in my case, but I thought it would be cleaner to make both configurable.
client/cli/src/commands/run_cmd.rs
Outdated
#[structopt(long = "rpc-max-in-buffer-capacity")] | ||
pub ws_max_in_buffer_capacity: Option<usize>, | ||
|
||
/// Set the the maximum RPC output buffer size. Default is 10MiB. |
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 does it relate to max payload setting? Wouldn't restricting it here further restrict the output max payload?
/// Set the the maximum RPC output buffer size. Default is 10MiB. | |
/// Set the the maximum RPC output buffer size in MiB. Default is 10. |
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 buffer seems to be the pre-cursor to the max-payload, at least for the output buffer. I presume you want to have your buffer size be x
and your max payload size 80% of x
in most cases. But now, we allow max payload to be high like 100 MiB (don't ask why, assume some teams that don't care about DOS need it :p), but with a buffer of 10 MiB your max payload is useless.
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.
but with a buffer of 10 MiB your max payload is useless.
Right, perhaps best to detect such misconfiguration and quit with an error then? I think it might be confusing to see large requests fail because they are limited by some other factor.
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 can do this if you agree with setting the default buffer size to 16 MiB, with the default max payload remaining 15 MiB. Then I can add a warning if the max out buffer is ever less than max payload.
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.
applied. I think it is pretty safe, WDYT?
Co-authored-by: Tomasz Drwięga <tomusdrw@users.noreply.github.com>
Co-authored-by: Tomasz Drwięga <tomusdrw@users.noreply.github.com>
Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>
…figurable-ws-buffer-size
…ch/substrate into kiz-configurable-ws-buffer-size
…figurable-ws-buffer-size
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.
Few grumbles, but lgtm otherwise!
Co-authored-by: Tomasz Drwięga <tomusdrw@users.noreply.github.com>
bot merge |
Waiting for commit status. |
* make the ws buffer size configurable * Update client/cli/src/commands/run_cmd.rs Co-authored-by: Tomasz Drwięga <tomusdrw@users.noreply.github.com> * Update client/cli/src/commands/run_cmd.rs Co-authored-by: Tomasz Drwięga <tomusdrw@users.noreply.github.com> * Update client/cli/src/commands/run_cmd.rs Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com> * Final touches * Apply suggestions from code review * fix bench * remove in buffer * Apply suggestions from code review Co-authored-by: Tomasz Drwięga <tomusdrw@users.noreply.github.com> Co-authored-by: Tomasz Drwięga <tomusdrw@users.noreply.github.com> Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>
* make the ws buffer size configurable * Update client/cli/src/commands/run_cmd.rs Co-authored-by: Tomasz Drwięga <tomusdrw@users.noreply.github.com> * Update client/cli/src/commands/run_cmd.rs Co-authored-by: Tomasz Drwięga <tomusdrw@users.noreply.github.com> * Update client/cli/src/commands/run_cmd.rs Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com> * Final touches * Apply suggestions from code review * fix bench * remove in buffer * Apply suggestions from code review Co-authored-by: Tomasz Drwięga <tomusdrw@users.noreply.github.com> Co-authored-by: Tomasz Drwięga <tomusdrw@users.noreply.github.com> Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>
I know this is not populare, but hear me out:
I am running into similar issues as in paritytech/polkadot#2039 in staking miners, and I don't see any other clear way to fix this.
In the issue, it was mentioned that this happened due to the speed of the consumer and producer not matching. Given the 10mb default, I am pretty sure it my case it is happening because a single storage item is somewhere above 10mb.
If at least one of @tomusdrw or @bkchr give a thumb up, will remove draft and document the code a bit better. I can also group all RPC-server related params into one struct to make it cleaner.
Polkadot companion: paritytech/polkadot#4078