Dynamically Configurable ThreadPool sizes

[allenss-amazon]

Making the threadpool sizes dynamically configurable would be a huge boon development testing and characterization.

[dpbnasika]

hey @allenss-amazon , i would like to work on this.

[allenss-amazon]

Go for it! Having this as a feature will really help developers. There's all sorts of testing situations where being able to dynamically change the # of threads is really helpful.

[yairgott]

One of the drawback of dynamically adjusting the thread pool size is that it involve more complication and potentially more contention.

I would like to better understand the use-case when it's expected to be useful.

[allenss-amazon]

Operationally, I've sometimes found that when investigating a problem that's live and persisting that by manipulating the # of threads and their mutual priority that either the situation resolved OR a better understanding of the problem was obtained.

Also when doing tuning for different instance sizes, etc and chasing latency vs throughput issues that manipulating the thread count substantially reduces the time to resolution.

I don't understand why dynamically changing the thread-count vs statically changing the thread-count would affect contention.

I do agree that dynamically changing the thread pool size can be complicated. But perhaps @dpbnasika can generate code that's simple enough to have confidence in it's stability and clarity.

[dpbnasika]

@allenss-amazon i have gone through the source, is this where it is hardcoded?. and do we need this to dynamically configure?.

struct Parameters { int reader_threads{10}; int writer_threads{30}; std::optional<int> threads; bool use_coordinator{false}; std::optional<std::string> log_level; };

but i would like to have a bit intro to the dev environment, perhaps, in the call i would also like to join on wednesday, as i am very new to this project and would like to understand the workflow and get a basic understanding of the project. would that be fine?.

[allenss-amazon]

I believe that those are where the default values are set. I believe that those can be overridden at module load time.

You're welcome to join the wednesday call.