Оффлайн
- Регистрация
- 1 Мар 2015
- Сообщения
- 1,481
- Баллы
- 155
I've created a "tune API" for the next version of . Essentially, "Tune" allows you to increase or decrease the size of the worker/thread pool at runtime.
For example, when the load on your server is high, you'll need to process more concurrent jobs. Conversely, when the load is low, you don't need as many workers, because workers consume resources.
Therefore, based on your custom logic, you can dynamically change the worker pool size using this tune API.
In this video, I've enqueued 1000 jobs into , and I've set the initial worker pool size to 10 (the concurrency value).
Every second, using the tune API, I'm increasing the worker pool size by 10 until it reaches 100.
Once it reaches a size of 100, then I start removing 10 workers at a time from the pool.
This way, I'm decreasing and then increasing the worker pool size.
Cool, right?
primarily uses an Event-Loop internally to handle this concurrency.
This event loop checks if there are any pending jobs in the queue and if any workers are available in the worker pool. If there are, it distributes jobs to all available workers and then goes back into sleep mode.
When a worker becomes free, it then tells the event loop, "Hey, I'm free now; if you have any jobs, you can give them to me."
The event loop then checks again if there are any pending jobs in the queue. If there are, it continues to distribute them to the workers.
This is concurrency model.
For example, when the load on your server is high, you'll need to process more concurrent jobs. Conversely, when the load is low, you don't need as many workers, because workers consume resources.
Therefore, based on your custom logic, you can dynamically change the worker pool size using this tune API.
In this video, I've enqueued 1000 jobs into , and I've set the initial worker pool size to 10 (the concurrency value).
Every second, using the tune API, I'm increasing the worker pool size by 10 until it reaches 100.
Once it reaches a size of 100, then I start removing 10 workers at a time from the pool.
This way, I'm decreasing and then increasing the worker pool size.
Cool, right?
primarily uses an Event-Loop internally to handle this concurrency.
This event loop checks if there are any pending jobs in the queue and if any workers are available in the worker pool. If there are, it distributes jobs to all available workers and then goes back into sleep mode.
When a worker becomes free, it then tells the event loop, "Hey, I'm free now; if you have any jobs, you can give them to me."
The event loop then checks again if there are any pending jobs in the queue. If there are, it continues to distribute them to the workers.
This is concurrency model.