Open vfssantos opened 1 year ago
uki00a
commented
11 months ago @vfssantos Thanks for the feedback!
node-redis implements Auto-Pipelining and Connection pooling. In contrast, deno-redis does not yet implement these features. Therefore, deno-redis basically processes commands sequentially.
We would like to support these features in deno-redis as well, although it will take some time. :pray:
esroyo
commented
1 month ago Just want to point-out that the node-redis client has by default a single connection, unless you create the client passing specific isolationPoolOptions (see https://github.com/redis/node-redis/issues/2720).
Therefore I guess the distinguishing feature is the auto-pipelining.
Implementing a connection pool outside of the client itself is trivial, using the same generic-pool lib that node-redis uses:
import { connect, type Redis } from "https://deno.land/x/redis/mod.ts";
import { createPool } from "npm:generic-pool";
const redisPool = createPool<Redis>({
create: async () => connect({ hostname: "127.0.0.1", port: "6379" }),
destroy: async (client) => client.close(),
}, { max: 20, min: 1 });
const startTime = new Date().getTime();
const promiseResponse = Array(100).fill(0).map(async () => {
const redisClient = await redisPool.acquire();
const res = await redisClient.get("foo");
await redisPool.release(redisClient);
console.log("time", new Date().getTime() - startTime);
return res;
});
const res = await Promise.all(promiseResponse);
// Drain the pool during shutdown
await redisPool.drain();
await redisPool.clear();It does indeed perform better, at the cost of more connections. Personally I'm fine implementing the pool myself, I like to keep the client simple :shrug:
EDIT: BTW, on node-redis auto-pipelining takes effect for commands executed exactly during the same event loop tick. I'm not sure it is that common to send many different commands on the same exact tick. Wouldn't in an HTTP server each request get handled on a different tick? :thinking: May be auto-pipelining gets more important for scripting scenarios, but for that you may use explicit pipelining, right?
I'm experiencing a performance issue with this module, that does not happen using 'npm:redis' module for Deno.
Basically, using a singleton instance
If I perform many parallel request using this same connection, such as:
It looks like the requests are being performed sequentially, instead of in parallel. Here are the "time" logs for a test I've performed:
The fact that it it consistently increasing indicates that there's something not allowing the requests to be performed in parallel with this lib. However, using the exact same code, but importing the 'redis' module from NPM, as
Here's the result:
Which clearly indicates that in fact the request ar being performed in parallel.
Is this the expected behavior of this module, or am I missing something here; or this behavior is indeed something which was not expected in this module?