Support for ioredis part 2

[maritz]

Continuation of #137

Huge thanks to @thepipster!

Open tasks:

• Documentation (just a few words and one example, I guess) ✔️
• Benchmarking ✔️

[maritz]

Hm, so for the simple stresstest benchmark using ioredis is actually quite a bit slower than node_redis.

ioredis

Starting stress test - saving and then updating 30000 models in parallel.
5578ms for 30000 parallel User saves, 5378.27 saves/second
Saves done, starting updates
3754ms for 30000 parallel User updates, 7991.48 updates/second
Total time: 9333ms

node_redis

Starting stress test - saving and then updating 30000 models in parallel.
4277ms for 30000 parallel User saves, 7014.26 saves/second
Saves done, starting updates
2335ms for 30000 parallel User updates, 12847.97 updates/second
Total time: 6612ms

(I did several of those, also tried 3000 and 10000 iterations, similar results)

So going from node_redis to ioredis incurs about 20-25% performance loss on saves. There is also an increased memory cost for ioredis in this test, but my measurements there are much less consistent. They point to about a 20% increase in memory used as well.

I would have assumed that the difference would be in ioredis' favor and would be much smaller. There might be simple explanations for this and this might not apply to real-world applications at all. When is an application going to do 30000 requests in parallel like this stress test? (they are all started as fast as possible in a single for loop, so backpressure handling in the redis client is most likely a factor).

So I will advise against using ioredis for nohm. You can still use ioredis in the rest of your application and just use node_redis for nohm, as far as I know the two should not cause conflicts.

[maritz]

@thepipster do you think this is enough documentation for it? Should be different maybe?

Btw: Do you have a specific need why you need ioredis? Would you be able to test sharding or cluster support or work on it if it doesn't work?

[thepipster]

Thanks, yeah the specific need is cluster support. Bummer about the performance, that is interesting.

[maritz]

Merged and published as v2.2.0