async-limiter

What is async-limiter?

The async-limiter package is a module that allows you to limit the number of asynchronous operations that are being processed at the same time. This is useful for controlling resource usage and managing load under high-concurrency situations.

What are async-limiter's main functionalities?

Concurrency Limiting

This code sample demonstrates how to use async-limiter to limit the number of concurrent asynchronous tasks. In this example, the concurrency limit is set to 2, meaning only two tasks will be processed at a time.

const Limiter = require('async-limiter');

const t = new Limiter({ concurrency: 2 });

for (let i = 0; i < 10; i++) {
  t.push((cb) => {
    setTimeout(() => {
      console.log('Processed task', i);
      cb();
    }, 100);
  });
}

t.onDone(() => {
  console.log('All tasks processed');
});

Other packages similar to async-limiter

bottleneck

Bottleneck is a powerful rate limiter that allows you to throttle functions and prioritize job queues. It provides more advanced features like clustering support and job scheduling compared to async-limiter.

p-limit

p-limit is a package that limits the number of promises running at the same time. It is similar to async-limiter but works specifically with promises, providing a simple API to control concurrency.

async

Async is a utility module which provides straight-forward, powerful functions for working with asynchronous JavaScript. It offers more than just limiting, including a wide range of functions for control flow, collection processing, and utilities. It's more comprehensive than async-limiter.

README

Async-Limiter

A module for limiting concurrent asynchronous actions in flight. Forked from queue.

This module exports a class Limiter that implements some of the Array API. Pass async functions (ones that accept a callback or return a promise) to an instance's additive array methods.

Motivation

Certain functions, like zlib, have undesirable behavior when run at infinite concurrency.

In this case, it is actually faster, and takes far less memory, to limit concurrency.

This module should do the absolute minimum work necessary to queue up functions. PRs are welcome that would make this module faster or lighter, but new functionality is not desired.

Style should confirm to nodejs/node style.

Example

var Limiter = require('async-limiter');

var t = new Limiter({ concurrency: 2 });
var results = [];

// add jobs using the familiar Array API
t.push(function(cb) {
  results.push('two');
  cb();
});

t.push(
  function(cb) {
    results.push('four');
    cb();
  },
  function(cb) {
    results.push('five');
    cb();
  }
);

t.unshift(function(cb) {
  results.push('one');
  cb();
});

t.splice(2, 0, function(cb) {
  results.push('three');
  cb();
});

// Jobs run automatically on the next tick.
// If you want a callback when all are done, call 'onDone()'.
t.onDone(function() {
  console.log('all done:', results);
});

Zlib Example

const zlib = require('zlib');
const Limiter = require('async-limiter');

const message = { some: 'data' };
const payload = new Buffer(JSON.stringify(message));

// Try with different concurrency values to see how this actually
// slows significantly with higher concurrency!
//
// 5:        1398.607ms
// 10:       1375.668ms
// Infinity: 4423.300ms
//
const t = new Limiter({ concurrency: 5 });
function deflate(payload, cb) {
  t.push(function(done) {
    zlib.deflate(payload, function(err, buffer) {
      done();
      cb(err, buffer);
    });
  });
}

console.time('deflate');
for (let i = 0; i < 30000; ++i) {
  deflate(payload, function(err, buffer) {});
}
t.onDone(function() {
  console.timeEnd('deflate');
});

Install

npm install async-limiter

Test

npm test

API

var t = new Limiter([opts])

Constructor. opts may contain inital values for:

• t.concurrency

Instance methods

t.onDone(fn)

fn will be called once and only once, when the queue is empty. If the queue is empty on the next tick, onDone() will be called.

Instance methods mixed in from Array

Mozilla has docs on how these methods work here.

t.push(element1, ..., elementN)

t.unshift(element1, ..., elementN)

t.splice(index , howMany[, element1[, ...[, elementN]]])

On the next tick, job processing will start.

Properties

t.concurrency

Max number of jobs the queue should process concurrently, defaults to Infinity.

t.length

Jobs pending + jobs to process (readonly).

Changelog

v2.0.0 (2019-11-20)

This release contains minor breaking changes. These changes should not affect most applications.

Breaking:

• Jobs will not start until the next tick (process.nextTick) after the first job is added. This allows you to order multiple jobs synchronously without unexpected effects.

This should align the limiter closer to programmer expectations, but is technically breaking: the current code will immediately begin executing the first job as soon as it is pushed.

This change also fixes a few edge-case bugs related to ordering & sync jobs:

• If an onDone() callback were added before any jobs were added in the same tick, it would be immediately called.
• If a synchronous job were added, it would immediately execute completely and potentially call onDone().

Other changes:

• Internals refactoring
• Fix example calling start() (queue starts automatically)