heavy load: increase timeouts and retries for spinning of transaction #7
Conversation
| @@ -19,6 +19,11 @@ use super::mode::{as_file_kind, as_file_perm, make_mode}; | |||
| use super::reply::{DirItem, StatFs}; | |||
| use super::tikv_fs::{DIR_PARENT, DIR_SELF}; | |||
|
|
|||
| // default from tikv-rust-client: no_jitter_backoff(base_delay_ms: 2, max_delay_ms: 500, max_attempts: 10) | |||
| pub const DEFAULT_REGION_BACKOFF: Backoff = Backoff::no_jitter_backoff(300, 1000, 100); | |||
| // default from tikv-rust-client: no_jitter_backoff(base_delay_ms: 2, max_delay_ms: 500, max_attempts: 10) | |||
There was a problem hiding this comment.
Please keep the comments consist with the real value.
There was a problem hiding this comment.
It's intendend that they differ. I put them as reference to show what the defaults are.
Anyway. Meanwhile I did some further testing and it seems that I have some issues with the WIFI. When I do the same test with a cable ethernet connection to the cluster, results are much better. So I think its probably better to implement a command line option that switches two predefined set of values. E.g. one for "Low Latency Networks" and one for "Wireless/Mobile" connections.
What do you think?
There was a problem hiding this comment.
In my opinion, I prefer to setting a low base_delay_ms as the default value, and left a command option and description to hint users to use a higher base_delay_ms in unstable network. The max_attempts can be a constant value, and the max_delay_ms may be N * base_delay_ms.
Providing two options to be suitable for different network environments is a black-box.
|
sorry, I lost the interest on this topic for now. Maybe I come back later again. But for now I close the PR as it doesn't have a priority for me. @Hexilee Thanks for your time that you spend on giving me feedback. If you think this PR is of importance for you, please tell me, then I would try to find a bit of time to finish it. |
Hello,
this was the next step (related to #5) I did for increasing robustness:
Increasing the timeouts and spinning delays.
I took as base values the ones that the tikv-client does by default and increased it according my gut-feeling.
I'm not an expert there and I also didn't do testing of other values and combinations,
therefor I do not guarantee for potential side effects.
Still I think it makes sence to have the option to tune these parameters. Which this PR allows.
Kind regards,
cre4ture