Skip to content
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

feat: support dynamic configuration for dynamic batching without service restart #448

Open
wenzhaojie opened this issue Oct 5, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@wenzhaojie
Copy link

Describe the feature

We can set parameters such as num=1, max_batch_size=4, max_wait_time=10 within append_worker(). However, we cannot modify these parameters during the service's runtime. Is it possible to provide a corresponding API to adjust the service parameters?

Why do you need this feature?

If we can implement this control API, we can adjust resource configurations without restarting the service, achieving dynamic changes in QoS (Quality of Service).

Additional context

No response

@wenzhaojie wenzhaojie added the enhancement New feature or request label Oct 5, 2023
@wenzhaojie wenzhaojie changed the title feat: Support Dynamic configuration for dynamic batching without service restart feat: Support dynamic configuration for dynamic batching without service restart Oct 5, 2023
@wenzhaojie wenzhaojie changed the title feat: Support dynamic configuration for dynamic batching without service restart feat: support dynamic configuration for dynamic batching without service restart Oct 6, 2023
@kemingy
Copy link
Member

kemingy commented Oct 6, 2023

Thanks for your feedback.

num is used by Python side to control how many multiprocesses to run. max_batch_size and max_wait_time are used by Rust side to route the requests. Also, only rust side has the web interface. If we need to change all of them, then Python main process might need to register a SIGUSR1 handler. This also requires a lock to sync the configuration between tokio threads. Restarting the container with a different arguments might be easier for both developers and users. (But still welcome PR)

I think it's related to #382 though that one is fully automatic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants