node-cache vs cache-manager vs memjs vs memcached
Node.js Caching Libraries Comparison
1 Year
node-cachecache-managermemjsmemcachedSimilar Packages:
What's Node.js Caching Libraries?

Caching libraries in Node.js are essential for improving application performance by temporarily storing frequently accessed data in memory. They help reduce latency and the number of database queries, leading to faster response times and a more efficient use of resources. Each library offers unique features and capabilities to cater to different caching needs, such as in-memory caching, distributed caching, and support for various backends.

Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
Package
Downloads
Stars
Size
Issues
Publish
License
node-cache3,600,2272,315-745 years agoMIT
cache-manager2,012,5811,78049.5 kB36 days agoMIT
memjs200,03120288.5 kB28a year agoMIT
memcached162,0931,315-1339 years agoMIT
Feature Comparison: node-cache vs cache-manager vs memjs vs memcached

Caching Strategy

  • node-cache:

    node-cache is an in-memory caching solution that operates within a single Node.js instance. It is designed for simplicity and ease of use, making it suitable for applications that do not require distributed caching.

  • cache-manager:

    cache-manager supports multiple caching strategies and backends, allowing you to choose the most appropriate one for your application. It can easily switch between in-memory, Redis, and Memcached, providing flexibility in how you manage cached data.

  • memjs:

    memjs is a client for Memcached that provides a straightforward API for caching data. It focuses on simplicity and performance, allowing developers to easily integrate Memcached into their applications without complex configurations.

  • memcached:

    memcached is designed specifically for distributed caching, focusing on speed and efficiency. It uses a simple key-value store model, making it easy to cache and retrieve data quickly across multiple servers, which is ideal for high-load applications.

Performance

  • node-cache:

    node-cache offers excellent performance for in-memory caching, with minimal overhead. It is suitable for applications with moderate caching needs and provides fast read and write operations, but it is limited to a single instance.

  • cache-manager:

    cache-manager's performance depends on the underlying store used. When using in-memory caching, it provides fast access times, but when using external stores like Redis or Memcached, network latency may affect performance. It is important to choose the right backend based on your application's needs.

  • memjs:

    memjs inherits the performance characteristics of Memcached, providing fast access to cached data. It is optimized for Node.js applications and can handle multiple requests efficiently, making it a reliable choice for caching in web applications.

  • memcached:

    memcached is known for its high performance and low latency, making it suitable for applications that require rapid access to cached data. It can handle a large number of concurrent connections and is optimized for speed, making it a popular choice for high-traffic applications.

Scalability

  • node-cache:

    node-cache is not designed for scalability beyond a single instance. It is best suited for small applications or microservices that do not require distributed caching capabilities, limiting its use in larger, more complex systems.

  • cache-manager:

    cache-manager can scale by integrating with distributed caching solutions like Redis or Memcached. This allows applications to handle increased loads by distributing cached data across multiple servers, improving performance and reliability as the application grows.

  • memjs:

    memjs scales with Memcached, allowing you to add more Memcached servers to your cluster. This makes it suitable for applications that need to scale out their caching layer to handle increased traffic and data volume.

  • memcached:

    memcached is inherently scalable, allowing you to add more servers to the cluster as needed. It can handle large datasets and high traffic by distributing the load across multiple nodes, making it ideal for applications that require horizontal scaling.

Ease of Use

  • node-cache:

    node-cache is extremely easy to set up and use, with minimal configuration required. It is ideal for developers looking for a quick and simple in-memory caching solution.

  • cache-manager:

    cache-manager provides a unified API that simplifies the process of implementing caching in your application. Its flexibility in choosing backends and straightforward configuration makes it easy to integrate into various projects.

  • memjs:

    memjs is designed for ease of use with a straightforward API that allows developers to quickly implement Memcached in their Node.js applications. Its simplicity makes it accessible for those new to caching.

  • memcached:

    memcached has a simple API for caching and retrieving data, making it easy to use for developers familiar with key-value stores. However, setting up a distributed environment may require additional configuration.

Expiration and TTL

  • node-cache:

    node-cache allows you to set expiration times for cached items, enabling automatic removal of stale data. This feature is useful for managing memory and ensuring that your application serves current data.

  • cache-manager:

    cache-manager supports setting expiration times and time-to-live (TTL) for cached items, allowing you to control how long data remains in the cache. This feature is essential for managing stale data and ensuring that your application serves fresh content.

  • memjs:

    memjs supports setting expiration times for cached items, which helps manage the lifecycle of cached data. This is important for applications that require up-to-date information and want to avoid serving stale content.

  • memcached:

    memcached allows you to set expiration times for cached items, which helps manage memory usage and ensures that stale data is removed from the cache. This feature is crucial for maintaining data consistency in applications with frequently changing data.

How to Choose: node-cache vs cache-manager vs memjs vs memcached
  • node-cache:

    Use node-cache if you need a simple, in-memory caching solution for a single Node.js instance. It is lightweight and easy to implement, making it ideal for small applications or microservices that do not require distributed caching capabilities.

  • cache-manager:

    Choose cache-manager if you need a versatile caching solution that can work with multiple backends, including in-memory, Redis, and Memcached. It provides a unified API and is suitable for applications that may require switching between different caching strategies without significant code changes.

  • memjs:

    Select memjs if you specifically want a Memcached client for Node.js that is easy to use and integrates well with existing Memcached installations. It provides a simple API for interacting with Memcached servers and is suitable for applications that require a lightweight and straightforward caching solution without additional overhead.

  • memcached:

    Opt for memcached if you're looking for a high-performance distributed memory caching system. It is ideal for applications that require fast access to shared data across multiple servers and can handle large amounts of data efficiently. Memcached is best suited for scenarios where you need to cache objects and session data in a distributed environment.

README for node-cache

Logo

Node.js CI Dependency status NPM package version NPM monthly downloads GitHub issues Coveralls Coverage

Simple and fast NodeJS internal caching.

A simple caching module that has set, get and delete methods and works a little bit like memcached. Keys can have a timeout (ttl) after which they expire and are deleted from the cache. All keys are stored in a single object so the practical limit is at around 1m keys.

BREAKING MAJOR RELEASE v5.x

The recent 5.x release:

  • dropped support for node versions before 8.x!
  • removed the callback-based api from all methods (you can re-enable them with the option enableLegacyCallbacks)

BREAKING MAJOR RELEASE v6.x UPCOMING

Although not breaking per definition, our typescript rewrite will change internal functions and their names. Please get in contact with us, if you are using some parts of node-cache's internal api so we can work something out!

Install

	npm install node-cache --save

Or just require the node_cache.js file to get the superclass

Examples:

Initialize (INIT):

const NodeCache = require( "node-cache" );
const myCache = new NodeCache();

Options

  • stdTTL: (default: 0) the standard ttl as number in seconds for every generated cache element. 0 = unlimited
  • checkperiod: (default: 600) The period in seconds, as a number, used for the automatic delete check interval. 0 = no periodic check.
  • useClones: (default: true) en/disable cloning of variables. If true you'll get a copy of the cached variable. If false you'll save and get just the reference.
    Note:
    • true is recommended if you want simplicity, because it'll behave like a server-based cache (it caches copies of plain data).
    • false is recommended if you want to achieve performance or save mutable objects or other complex types with mutability involved and wanted, because it'll only store references of your data.
    • Here's a simple code example showing the different behavior
  • deleteOnExpire: (default: true) whether variables will be deleted automatically when they expire. If true the variable will be deleted. If false the variable will remain. You are encouraged to handle the variable upon the event expired by yourself.
  • enableLegacyCallbacks: (default: false) re-enables the usage of callbacks instead of sync functions. Adds an additional cb argument to each function which resolves to (err, result). will be removed in node-cache v6.x.
  • maxKeys: (default: -1) specifies a maximum amount of keys that can be stored in the cache. If a new item is set and the cache is full, an error is thrown and the key will not be saved in the cache. -1 disables the key limit.
const NodeCache = require( "node-cache" );
const myCache = new NodeCache( { stdTTL: 100, checkperiod: 120 } );

Since 4.1.0: Key-validation: The keys can be given as either string or number, but are casted to a string internally anyway. All other types will throw an error.

Store a key (SET):

myCache.set( key, val, [ ttl ] )

Sets a key value pair. It is possible to define a ttl (in seconds). Returns true on success.

obj = { my: "Special", variable: 42 };

success = myCache.set( "myKey", obj, 10000 );
// true

Note: If the key expires based on it's ttl it will be deleted entirely from the internal data object.

Store multiple keys (MSET):

myCache.mset(Array<{key, val, ttl?}>)

Sets multiple key val pairs. It is possible to define a ttl (seconds). Returns true on success.

const obj = { my: "Special", variable: 42 };
const obj2 = { my: "other special", variable: 1337 };

const success = myCache.mset([
	{key: "myKey", val: obj, ttl: 10000},
	{key: "myKey2", val: obj2},
])

Retrieve a key (GET):

myCache.get( key )

Gets a saved value from the cache. Returns a undefined if not found or expired. If the value was found it returns the value.

value = myCache.get( "myKey" );
if ( value == undefined ){
	// handle miss!
}
// { my: "Special", variable: 42 }

Since 2.0.0:

The return format changed to a simple value and a ENOTFOUND error if not found *( as result instance of Error )

Since 2.1.0:

The return format changed to a simple value, but a due to discussion in #11 a miss shouldn't return an error. So after 2.1.0 a miss returns undefined.

Take a key (TAKE):

myCache.take( key )

get the cached value and remove the key from the cache.
Equivalent to calling get(key) + del(key).
Useful for implementing single use mechanism such as OTP, where once a value is read it will become obsolete.

myCache.set( "myKey", "myValue" )
myCache.has( "myKey" ) // returns true because the key is cached right now
value = myCache.take( "myKey" ) // value === "myValue"; this also deletes the key
myCache.has( "myKey" ) // returns false because the key has been deleted

Get multiple keys (MGET):

myCache.mget( [ key1, key2, ..., keyn ] )

Gets multiple saved values from the cache. Returns an empty object {} if not found or expired. If the value was found it returns an object with the key value pair.

value = myCache.mget( [ "myKeyA", "myKeyB" ] );
/*
	{
		"myKeyA": { my: "Special", variable: 123 },
		"myKeyB": { the: "Glory", answer: 42 }
	}
*/

Since 2.0.0:

The method for mget changed from .get( [ "a", "b" ] ) to .mget( [ "a", "b" ] )

Delete a key (DEL):

myCache.del( key )

Delete a key. Returns the number of deleted entries. A delete will never fail.

value = myCache.del( "A" );
// 1

Delete multiple keys (MDEL):

myCache.del( [ key1, key2, ..., keyn ] )

Delete multiple keys. Returns the number of deleted entries. A delete will never fail.

value = myCache.del( "A" );
// 1

value = myCache.del( [ "B", "C" ] );
// 2

value = myCache.del( [ "A", "B", "C", "D" ] );
// 1 - because A, B and C not exists

Change TTL (TTL):

myCache.ttl( key, ttl )

Redefine the ttl of a key. Returns true if the key has been found and changed. Otherwise returns false. If the ttl-argument isn't passed the default-TTL will be used.

The key will be deleted when passing in a ttl < 0.

myCache = new NodeCache( { stdTTL: 100 } )
changed = myCache.ttl( "existentKey", 100 )
// true

changed2 = myCache.ttl( "missingKey", 100 )
// false

changed3 = myCache.ttl( "existentKey" )
// true

Get TTL (getTTL):

myCache.getTtl( key )

Receive the ttl of a key. You will get:

  • undefined if the key does not exist
  • 0 if this key has no ttl
  • a timestamp in ms representing the time at which the key will expire
myCache = new NodeCache( { stdTTL: 100 } )

// Date.now() = 1456000500000
myCache.set( "ttlKey", "MyExpireData" )
myCache.set( "noTtlKey", "NonExpireData", 0 )

ts = myCache.getTtl( "ttlKey" )
// ts wil be approximately 1456000600000

ts = myCache.getTtl( "ttlKey" )
// ts wil be approximately 1456000600000

ts = myCache.getTtl( "noTtlKey" )
// ts = 0

ts = myCache.getTtl( "unknownKey" )
// ts = undefined

List keys (KEYS)

myCache.keys()

Returns an array of all existing keys.

mykeys = myCache.keys();

console.log( mykeys );
// [ "all", "my", "keys", "foo", "bar" ]

Has key (HAS)

myCache.has( key )

Returns boolean indicating if the key is cached.

exists = myCache.has( 'myKey' );

console.log( exists );

Statistics (STATS):

myCache.getStats()

Returns the statistics.

myCache.getStats();
	/*
		{
			keys: 0,    // global key count
			hits: 0,    // global hit count
			misses: 0,  // global miss count
			ksize: 0,   // global key size count in approximately bytes
			vsize: 0    // global value size count in approximately bytes
		}
	*/

Flush all data (FLUSH):

myCache.flushAll()

Flush all data.

myCache.flushAll();
myCache.getStats();
	/*
		{
			keys: 0,    // global key count
			hits: 0,    // global hit count
			misses: 0,  // global miss count
			ksize: 0,   // global key size count in approximately bytes
			vsize: 0    // global value size count in approximately bytes
		}
	*/

Flush the stats (FLUSH STATS):

myCache.flushStats()

Flush the stats.

myCache.flushStats();
myCache.getStats();
	/*
		{
			keys: 0,    // global key count
			hits: 0,    // global hit count
			misses: 0,  // global miss count
			ksize: 0,   // global key size count in approximately bytes
			vsize: 0    // global value size count in approximately bytes
		}
	*/

Close the cache:

myCache.close()

This will clear the interval timeout which is set on check period option.

myCache.close();

Events

set

Fired when a key has been added or changed. You will get the key and the value as callback argument.

myCache.on( "set", function( key, value ){
	// ... do something ...
});

del

Fired when a key has been removed manually or due to expiry. You will get the key and the deleted value as callback arguments.

myCache.on( "del", function( key, value ){
	// ... do something ...
});

expired

Fired when a key expires. You will get the key and value as callback argument.

myCache.on( "expired", function( key, value ){
	// ... do something ...
});

flush

Fired when the cache has been flushed.

myCache.on( "flush", function(){
	// ... do something ...
});

flush_stats

Fired when the cache stats has been flushed.

myCache.on( "flush_stats", function(){
	// ... do something ...
});

Breaking changes

version 2.x

Due to the Issue #11 the return format of the .get() method has been changed!

Instead of returning an object with the key { "myKey": "myValue" } it returns the value itself "myValue".

version 3.x

Due to the Issue #30 and Issue #27 variables will now be cloned. This could break your code, because for some variable types ( e.g. Promise ) its not possible to clone them. You can disable the cloning by setting the option useClones: false. In this case it's compatible with version 2.x.

version 5.x

Callbacks are deprecated in this version. They are still useable when enabling the enableLegacyCallbacks option when initializing the cache. Callbacks will be completely removed in 6.x.

Compatibility

Node-Cache supports all node versions >= 8

Release History

|Version|Date|Description| |:--:|:--:|:--| |5.1.1|2020-06-06|[#184], [#183] thanks Jonah Werre for reporting [#181]!, [#180], Thanks Titus for [#169]!, Thanks Ianfeather for [#168]!, Thanks Adam Haglund for [#176]| |5.1.0|2019-12-08|Add .take() from PR [#160] and .flushStats from PR [#161]. Thanks to Sujesh Thekkepatt and Gopalakrishna Palem!| |5.0.2|2019-11-17|Fixed bug where expired values were deleted even though deleteOnExpire was set to false. Thanks to fielding-wilson!| |5.0.1|2019-10-31|Fixed bug where users could not set null values. Thanks to StefanoSega, jwest23 and marudor!| |5.0.0|2019-10-23|Remove lodash dependency, add .has(key) and .mset([{key,val,ttl}]) methods to the cache. Thanks to Regev Brody for PR [#132] and Sujesh Thekkepatt for PR [#142]! Also thank you, to all other contributors that remain unnamed here!| |4.2.1|2019-07-22|Upgrade lodash to version 4.17.15 to suppress messages about unrelated security vulnerability| |4.2.0|2018-02-01|Add options.promiseValueSize for promise value. Thanks to Ryan Roemer for the pull [#84]; Added option deleteOnExpire; Added DefinitelyTyped Typescript definitions. Thanks to Ulf Seltmann for the pulls [#90] and [#92]; Thanks to Daniel Jin for the readme fix in pull [#93]; Optimized test and ci configs.| |4.1.1|2016-12-21|fix internal check interval for node < 0.10.25, thats the default node for ubuntu 14.04. Thanks to Jimmy Hwang for the pull #78; added more docker tests| |4.1.0|2016-09-23|Added tests for different key types; Added key validation (must be string or number); Fixed .del bug where trying to delete a number key resulted in no deletion at all.| |4.0.0|2016-09-20|Updated tests to mocha; Fixed .ttl bug to not delete key on .ttl( key, 0 ). This is also relevant if stdTTL=0. This causes the breaking change to 4.0.0.| |3.2.1|2016-03-21|Updated lodash to 4.x.; optimized grunt | |3.2.0|2016-01-29|Added method getTtl to get the time when a key expires. See #49| |3.1.0|2016-01-29|Added option errorOnMissing to throw/callback an error o a miss during a .get( "key" ). Thanks to David Godfrey for the pull #45. Added docker files and a script to run test on different node versions locally| |3.0.1|2016-01-13|Added .unref() to the checkTimeout so until node 0.10 it's not necessary to call .close() when your script is done. Thanks to Doug Moscrop for the pull #44.| |3.0.0|2015-05-29|Return a cloned version of the cached element and save a cloned version of a variable. This can be disabled by setting the option useClones:false. (Thanks for #27 to cheshirecatalyst and for #30 to Matthieu Sieben)| |~~2.2.0~~|~~2015-05-27~~|REVOKED VERSION, because of conficts. See Issue #30. So 2.2.0 is now 3.0.0| |2.1.1|2015-04-17|Passed old value to the del event. Thanks to Qix for the pull.| |2.1.0|2015-04-17|Changed get miss to return undefined instead of an error. Thanks to all #11 contributors | |2.0.1|2015-04-17|Added close function (Thanks to ownagedj). Changed the development environment to use grunt.| |2.0.0|2015-01-05|changed return format of .get() with a error return on a miss and added the .mget() method. Side effect: Performance of .get() up to 330 times faster!| |1.1.0|2015-01-05|added .keys() method to list all existing keys| |1.0.3|2014-11-07|fix for setting numeric values. Thanks to kaspars + optimized key ckeck.| |1.0.2|2014-09-17|Small change for better ttl handling| |1.0.1|2014-05-22|Readme typos. Thanks to mjschranz| |1.0.0|2014-04-09|Made callbacks optional. So it's now possible to use a syncron syntax. The old syntax should also work well. Push : Bugfix for the value 0| |0.4.1|2013-10-02|Added the value to expired event| |0.4.0|2013-10-02|Added nodecache events| |0.3.2|2012-05-31|Added Travis tests|

NPM

Other projects

|Name|Description| |:--|:--| |rsmq|A really simple message queue based on redis| |redis-heartbeat|Pulse a heartbeat to redis. This can be used to detach or attach servers to nginx or similar problems.| |systemhealth|Node module to run simple custom checks for your machine or it's connections. It will use redis-heartbeat to send the current state to redis.| |rsmq-cli|a terminal client for rsmq| |rest-rsmq|REST interface for.| |redis-sessions|An advanced session store for NodeJS and Redis| |connect-redis-sessions|A connect or express middleware to simply use the redis sessions. With redis sessions you can handle multiple sessions per user_id.| |redis-notifications|A redis based notification engine. It implements the rsmq-worker to safely create notifications and recurring reports.| |nsq-logger|Nsq service to read messages from all topics listed within a list of nsqlookupd services.| |nsq-topics|Nsq helper to poll a nsqlookupd service for all it's topics and mirror it locally.| |nsq-nodes|Nsq helper to poll a nsqlookupd service for all it's nodes and mirror it locally.| |nsq-watch|Watch one or many topics for unprocessed messages.| |hyperrequest|A wrapper around hyperquest to handle the results| |task-queue-worker|A powerful tool for background processing of tasks that are run by making standard http requests |soyer|Soyer is small lib for server side use of Google Closure Templates with node.js.| |grunt-soy-compile|Compile Goggle Closure Templates ( SOY ) templates including the handling of XLIFF language files.| |backlunr|A solution to bring Backbone Collections together with the browser fulltext search engine Lunr.js| |domel|A simple dom helper if you want to get rid of jQuery| |obj-schema|Simple module to validate an object by a predefined schema|

The MIT License (MIT)

Copyright © 2019 Mathias Peter and the node-cache maintainers, https://github.com/node-cache/node-cache

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 'Software'), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.