@ -152,8 +152,13 @@ So please attach the error listener to node_redis.
### "drain"
`client` will emit `drain` when the TCP connection to the Redis server has been buffering, but is now
writable. This event can be used to stream commands in to Redis and adapt to backpressure. Right now,
you need to check `client.command_queue.length` to decide when to reduce your send rate and resume sending commands when you get `drain`.
writable. This event can be used to stream commands in to Redis and adapt to backpressure.
All commands return a boolean if the stream had to buffer or not. If false is returned the stream had to buffer.
That way you can decide when to reduce your send rate and resume sending commands when you get `drain`.
You can manually control the low water and high water marks by passing ommand_queue_high_water` and `command_queue_low_water` to the client options.
Check the [Node.js streams API](https://nodejs.org/api/stream.html) for further info.
### "idle"
@ -403,6 +408,7 @@ channel name as `channel` and the new count of subscriptions for this client as
`MULTI` commands are queued up until an `EXEC` is issued, and then all commands are run atomically by
Redis. The interface in `node_redis` is to return an individual `Multi` object by calling `client.multi()`.
If any command fails to queue, all commands are rolled back and none is going to be executed (For further information look at [transactions](http://redis.io/topics/transactions)).
```js
var redis = require("./index"),
@ -486,6 +492,21 @@ client.multi([
});
```
### Multi.exec_atomic( callback )
Identical to Multi.exec but with the difference that executing a single command will not use transactions.
## client.batch([commands])
Identical to .multi without transactions. This is recommended if you want to execute many commands at once but don't have to rely on transactions.
`BATCH` commands are queued up until an `EXEC` is issued, and then all commands are run atomically by
Redis. The interface in `node_redis` is to return an individual `Batch` object by calling `client.batch()`.
The only difference between .batch and .multi is that no transaction is going to be used.
Be aware that the errors are - just like in multi statements - in the result. Otherwise both, errors and results could be returned at the same time.
If you fire many commands at once this is going to **boost the execution speed by up to 400%** [sic!] compared to fireing the same commands in a loop without waiting for the result! See the benchmarks for further comparison. Please remember that all commands are kept in memory until they are fired.
## Monitor mode
Redis supports the `MONITOR` command, which lets you see all commands received by the Redis server
@ -628,42 +649,59 @@ Here are results of `multi_bench.js` which is similar to `redis-benchmark` from
The peregrino falcon is the fasted bird on earth and this is what this release is all about: We increased performance for heavy usage by up to **400%** [sic!] and increased overall performance for any command as well. Please check the benchmarks in the [README.md](README.md) for further details.
Features
- Added disable_resubscribing option to prevent a client from resubscribing after reconnecting (@BridgeAR)
- Added rename_commands options to handle renamed commands from the redis config (@digmxl &@BridgeAR)
- Added rename_commands options to handle renamed commands from the redis config ([@digmxl](https://github.com/digmxl) & [@BridgeAR](https://github.com/BridgeAR))
- Added disable_resubscribing option to prevent a client from resubscribing after reconnecting ([@BridgeAR](https://github.com/BridgeAR))
- exchanging built in queue with [@petkaantonov](https://github.com/petkaantonov)'s [double-ended queue](https://github.com/petkaantonov/deque)
- prevent polymorphism
- optimize statements
- Added *.batch* command, similar to .multi but without transaction ([@BridgeAR](https://github.com/BridgeAR))
- Improved pipelining to minimize the [RTT](http://redis.io/topics/pipelining) further ([@BridgeAR](https://github.com/BridgeAR))
Bugfixes
- Fix a javascript parser regression introduced in 2.0 that could result in timeouts on high load. (@BridgeAR)
- Fix a javascript parser regression introduced in 2.0 that could result in timeouts on high load. ([@BridgeAR](https://github.com/BridgeAR))
- Fixed should_buffer boolean for .exec, .select and .auth commands not being returned and fix a couple special conditions ([@BridgeAR](https://github.com/BridgeAR))
If you do not rely on transactions but want to reduce the RTT you can use .batch from now on. It'll behave just the same as .multi but it does not have any transaction and therefor won't roll back any failed commands.<br>
Both .multi and .batch are from now on going to cache the commands and release them while calling .exec.
Please consider using .batch instead of looping through a lot of commands one by one. This will significantly improve your performance.
Here are some stats compared to ioredis 1.9.1:
simple set
82,496 op/s » ioredis
112,617 op/s » node_redis
simple get
82,015 op/s » ioredis
105,701 op/s » node_redis
simple get with pipeline
10,233 op/s » ioredis
26,541 op/s » node_redis
lrange 100
7,321 op/s » ioredis
26,155 op/s » node_redis
publish
90,524 op/s » ioredis
112,823 op/s » node_redis
subscribe
43,783 op/s » ioredis
61,889 op/s » node_redis
To conclude: we can proudly say that node_redis is very likely outperforming any other node redis client.
Ruben Bridgewater
9 years ago