Node pool contains two <a href="https://nodejs.org/api/worker_threads.html#worker_threads_worker_threads">worker-threads </a> pool implementations , you don' t have to deal with worker-threads complexity. <br>
The first implementation is a static thread pool , with a defined number of threads that are started at creation time and will be reused.<br>
<h2> Overview </h2>
Node pool contains two <a href="https://nodejs.org/api/worker_threads.html#worker_threads_worker_threads">worker-threads </a> pool implementations , you don' t have to deal with worker-threads complexity. <br>
The first implementation is a static thread pool , with a defined number of threads that are started at creation time and will be reused.<br>
-The second implementation is a dynamic thread pool with a number of threads started at creation time ( these threads will be always active and reused) and other threads created when the load will increase ( with an upper limit ), the new created threads will be stopped after a configurable period of inactivity. <br>
+The second implementation is a dynamic thread pool with a number of threads started at creation time ( these threads will be always active and reused) and other threads created when the load will increase ( with an upper limit, these threads will be reused when active ), the new created threads will be stopped after a configurable period of inactivity. <br>
You have to implement your worker extending the ThreadWorker class<br>
<h2 id="installation">Installation</h2>
```
You have to implement your worker extending the ThreadWorker class<br>
<h2 id="installation">Installation</h2>
```
-npm install node-thread-pool --save
+npm install poolifier --save
```
<h2 id="usage">Usage</h2>
```
<h2 id="usage">Usage</h2>
@@ -38,15+41,17 @@ You can implement a worker in a simple way , extending the class ThreadWorker :
```js
'use strict'
```js
'use strict'
-const { ThreadWorker } = require('node-pool')
+const { ThreadWorker } = require('poolifier')
+
+function yourFunction (data) {
+ // this will be executed in the worker thread,
+ // the data will be received by using the execute method
+ return { ok: 1 }
+}
class MyWorker extends ThreadWorker {
constructor () {
class MyWorker extends ThreadWorker {
constructor () {
- super((data) => {
- // this will be executed in the worker thread,
- // the data will be received by using the execute method
-<strong> See examples folder for more details.</strong>
+<strong> See examples folder for more details ( in particular if you want to use a pool for [multiple functions](./examples/multiFunctionExample.js) ).</strong>
<h2 id="nv">Node versions</h2>
<h2 id="nv">Node versions</h2>
-You can use node version 10.x with --experimental-worker flag, or you can use an higher version (i.e 12.x) <br>
+You can use node versions 12.x , 13.x <br>
<h2 id="api">API</h2>
<h2 id="api">API</h2>
@@ -113,12+121,12 @@ This method will call the terminate method on each worker.
- `maxInactiveTime` - Max time to wait tasks to work on ( in ms) , after this period the new worker threads will die.
<h2 id="cyp">Choose your pool</h2>
- `maxInactiveTime` - Max time to wait tasks to work on ( in ms) , after this period the new worker threads will die.
<h2 id="cyp">Choose your pool</h2>
-Performance is one of the main target of these thread pool implementation, we want to have a strong focus on this.<br>
+Performance is one of the main target of these thread pool implementations, we want to have a strong focus on this.<br>
We already have a bench folder where you can find some comparisons.
To choose your pool consider that with a FixedThreadPool or a DynamicThreadPool ( in this case is important the min parameter passed to the constructor) your application memory footprint will increase . <br>
We already have a bench folder where you can find some comparisons.
To choose your pool consider that with a FixedThreadPool or a DynamicThreadPool ( in this case is important the min parameter passed to the constructor) your application memory footprint will increase . <br>
-Increasing the memory footprint your application will be ready to accept more CPU bound tasks, but during idle time your application will consume more memory. <br>
+Increasing the memory footprint, your application will be ready to accept more CPU bound tasks, but during idle time your application will consume more memory. <br>
One good choose from my point of view is to profile your application using Fixed/Dynamic thread pool , and to see your application metrics when you increase/decrease the num of threads. <br>
One good choose from my point of view is to profile your application using Fixed/Dynamic thread pool , and to see your application metrics when you increase/decrease the num of threads. <br>
-For example you could keep the memory footprint low choosing a DynamicThreadPool with 5 threads, and allow to create new threads until 50/100 when requests, this is the advantage to use the DynamicThreadPool. <br>
+For example you could keep the memory footprint low choosing a DynamicThreadPool with 5 threads, and allow to create new threads until 50/100 when needed, this is the advantage to use the DynamicThreadPool. <br>
But in general , <strong>always profile your application </strong>
<h2 id="contribute">Contribute</h2>
But in general , <strong>always profile your application </strong>