You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+74-36Lines changed: 74 additions & 36 deletions
Original file line number
Diff line number
Diff line change
@@ -152,8 +152,13 @@ So please attach the error listener to node_redis.
152
152
### "drain"
153
153
154
154
`client` will emit `drain` when the TCP connection to the Redis server has been buffering, but is now
155
-
writable. This event can be used to stream commands in to Redis and adapt to backpressure. Right now,
156
-
you need to check `client.command_queue.length` to decide when to reduce your send rate and resume sending commands when you get `drain`.
155
+
writable. This event can be used to stream commands in to Redis and adapt to backpressure.
156
+
157
+
All commands return a boolean if the stream had to buffer or not. If false is returned the stream had to buffer.
158
+
That way you can decide when to reduce your send rate and resume sending commands when you get `drain`.
159
+
160
+
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.
161
+
Check the [Node.js streams API](https://nodejs.org/api/stream.html) for further info.
157
162
158
163
### "idle"
159
164
@@ -403,6 +408,7 @@ channel name as `channel` and the new count of subscriptions for this client as
403
408
404
409
`MULTI` commands are queued up until an `EXEC` is issued, and then all commands are run atomically by
405
410
Redis. The interface in `node_redis` is to return an individual `Multi` object by calling `client.multi()`.
411
+
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)).
406
412
407
413
```js
408
414
var redis =require("./index"),
@@ -486,6 +492,21 @@ client.multi([
486
492
});
487
493
```
488
494
495
+
### Multi.exec_atomic( callback )
496
+
497
+
Identical to Multi.exec but with the difference that executing a single command will not use transactions.
498
+
499
+
## client.batch([commands])
500
+
501
+
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.
502
+
503
+
`BATCH` commands are queued up until an `EXEC` is issued, and then all commands are run atomically by
504
+
Redis. The interface in `node_redis` is to return an individual `Batch` object by calling `client.batch()`.
505
+
The only difference between .batch and .multi is that no transaction is going to be used.
506
+
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.
507
+
508
+
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.
509
+
489
510
## Monitor mode
490
511
491
512
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
0 commit comments