4 ms·

What the diff with https://github.com/debasishg/scala-redis https://github.com/debasishg/scala-redis ? Almost every scala redis driver supports futures and is e

What the diff with https://github.com/debasishg/scala-redis https://github.com/debasishg/scala-redis ? Almost every scala redis driver supports futures and is easy to wrap it into futures. Also by making all redis call async we have noticed performance issues as redis serves only 1 req every time there was too much time spending in thread-join. We found that the best practice is to have non blocking requests (methods) and all the redis reads in a blocking way. The only way to gain speed it to have N redis CPU's with N threads but that's almost impossible.

etaty 13y ago
The main difference are the performance and a better support of commands (almost all of them are available right now). Rediscala matches redis type answer to scala types. Redis serves 1 req at a time, but you can write to Redis socket and read from Redis socket during that time. Rediscala (the RedisClient) use 2 actors: The first one handle I/O (I/O bounds). That actor also merge redis requests in a buffer, so there is less messages (but bigger) going to the TcpWorker (akka worker handling a tcp socket). The second decode replies (CPU bounds)
- weakwire 13y ago
  Really interesting. I'll try the Rediscala driver and let you know about performance then.
anorwell 13y ago
It looks like the asynchronous interface to debasishg/scala-redis is synchronous under the hood, using a pool of blocking connections. This means that there is no pipelining. Each of these blocking connections must wait for a request to travel over the wire, be handled by redis, and travel back before it can be reused. An asynchronous client allows full pipelining automatically, which is a much more efficient use of a single connection. > we have noticed performance issues as redis serves only 1 req every time there was too much time spending in thread-join Performance should be better with an asynchronous client. When I've benchmarked e.g. jedis vs various async clients, that's been the case.

etaty 13y ago

The main difference are the performance and a better support of commands (almost all of them are available right now). Rediscala matches redis type answer to scala types. Redis serves 1 req at a time, but you can write to Redis socket and read from Redis socket during that time. Rediscala (the RedisClient) use 2 actors: The first one handle I/O (I/O bounds). That actor also merge redis requests in a buffer, so there is less messages (but bigger) going to the TcpWorker (akka worker handling a tcp socket). The second decode replies (CPU bounds)

weakwire 13y ago
Really interesting. I'll try the Rediscala driver and let you know about performance then.

anorwell 13y ago

It looks like the asynchronous interface to debasishg/scala-redis is synchronous under the hood, using a pool of blocking connections. This means that there is no pipelining. Each of these blocking connections must wait for a request to travel over the wire, be handled by redis, and travel back before it can be reused. An asynchronous client allows full pipelining automatically, which is a much more efficient use of a single connection. > we have noticed performance issues as redis serves only 1 req every time there was too much time spending in thread-join Performance should be better with an asynchronous client. When I've benchmarked e.g. jedis vs various async clients, that's been the case.