- Easy to use :white_check_mark:
- Performance [benchmarks](./benchmarks/README.md) :white_check_mark:
-- Static and dynamic pool size :white_check_mark:
+- Fixed and dynamic pool size :white_check_mark:
- Easy switch from a pool type to another :white_check_mark:
- No runtime dependencies :white_check_mark:
-- Proper async integration with node [async_hooks](https://nodejs.org/api/async_hooks.html) :white_check_mark:
+- Proper integration with node [async_hooks](https://nodejs.org/api/async_hooks.html) :white_check_mark:
- Support CommonJS, ESM, and TypeScript :white_check_mark:
- Support for [worker_threads](https://nodejs.org/api/worker_threads.html) and [cluster](https://nodejs.org/api/cluster.html) Node.js modules :white_check_mark:
-- Support sync and async tasks :white_check_mark:
+- Support multiple task functions :white_check_mark:
+- Support sync and async task functions :white_check_mark:
- Tasks distribution strategies :white_check_mark:
- General guidance on pool choice :white_check_mark:
- Error handling out of the box :white_check_mark:
## Overview
-Poolifier contains two [worker_threads](https://nodejs.org/api/worker_threads.html#class-worker)/[cluster](https://nodejs.org/api/cluster.html#cluster_class_worker) worker pool implementations, you don't have to deal with worker*threads/cluster complexity.
-The first implementation is a static worker pool, with a defined number of workers that are started at creation time and will be reused.
+Poolifier contains two [worker_threads](https://nodejs.org/api/worker_threads.html#class-worker)/[cluster](https://nodejs.org/api/cluster.html#cluster_class_worker) worker pool implementations, you don't have to deal with [worker_threads](https://nodejs.org/api/worker_threads.html)/[cluster](https://nodejs.org/api/cluster.html) complexity.
+The first implementation is a fixed worker pool, with a defined number of workers that are started at creation time and will be reused.
The second implementation is a dynamic worker pool, with a number of worker started at creation time (these workers will be always active and reused) and other workers created when the load will increase (with an upper limit, these workers will be reused when active), the new created workers will be stopped after a configurable period of inactivity.
-You have to implement your worker by extending the \_ThreadWorker* or _ClusterWorker_ class.
+You have to implement your worker by extending the _ThreadWorker_ or _ClusterWorker_ class.
## Installation
// the execute method signature is the same for both implementations,
// so you can easy switch from one to another
pool
- .execute({})
+ .execute()
.then(res => {
console.info(res)
})
You can do the same with the classes _ClusterWorker_, _FixedClusterPool_ and _DynamicClusterPool_.
-**See [examples](./examples/) folder for more details (in particular if you want to use a pool with [multiple worker functions](./examples/multiFunctionExample.js))**.
+**See [examples](./examples/) folder for more details (in particular if you want to use a pool with [multiple task functions](./examples/multiFunctionExample.js))**.
Remember that workers can only send and receive structured-cloneable data.
- `WorkerChoiceStrategies.LEAST_BUSY`: Submit tasks to the worker with the minimum tasks total execution and wait time
- `WorkerChoiceStrategies.LEAST_ELU`: Submit tasks to the worker with the minimum event loop utilization (ELU) (experimental)
- `WorkerChoiceStrategies.WEIGHTED_ROUND_ROBIN`: Submit tasks to worker by using a [weighted round robin scheduling algorithm](./src/pools/selection-strategies/README.md#weighted-round-robin) based on tasks execution time
- - `WorkerChoiceStrategies.INTERLEAVED_WEIGHTED_ROUND_ROBIN`: Submit tasks to worker by using an [interleaved weighted round robin scheduling algorithm](./src/pools/selection-strategies/README.md#interleaved-weighted-round-robin) based on tasks execution time(experimental)
+ - `WorkerChoiceStrategies.INTERLEAVED_WEIGHTED_ROUND_ROBIN`: Submit tasks to worker by using an [interleaved weighted round robin scheduling algorithm](./src/pools/selection-strategies/README.md#interleaved-weighted-round-robin) based on tasks execution time (experimental)
- `WorkerChoiceStrategies.FAIR_SHARE`: Submit tasks to worker by using a [fair share scheduling algorithm](./src/pools/selection-strategies/README.md#fair-share) based on tasks execution time (the default) or ELU active time
`WorkerChoiceStrategies.WEIGHTED_ROUND_ROBIN`, `WorkerChoiceStrategies.INTERLEAVED_WEIGHTED_ROUND_ROBIN` and `WorkerChoiceStrategies.FAIR_SHARE` strategies are targeted to heavy and long tasks.
To choose your pool consider first that with a _FixedThreadPool_/_FixedClusterPool_ or a _DynamicThreadPool_/_DynamicClusterPool_ your application memory footprint will increase.
By doing so, your application will be ready to execute in parallel more tasks, but during idle time your application will consume more memory.
-One good choice from poolifier team point of view is to profile your application using a static or dynamic worker pool, and analyze your application metrics when you increase/decrease the number of workers.
+One good choice from poolifier team point of view is to profile your application using a fixed or dynamic worker pool, and analyze your application metrics when you increase/decrease the number of workers.
For example you could keep the memory footprint low by choosing a _DynamicThreadPool_/_DynamicClusterPool_ with a minimum of 5 workers, and allowing it to create new workers until a maximum of 50 workers if needed. This is the advantage of using a _DynamicThreadPool_/_DynamicClusterPool_.
But in general, **always profile your application**.
repositories / poolifier.git / blobdiff