Connection pooling?

[fictorial]

Connection pooling?

[fictorial]

The idea is to create a client once and reuse it across many logical application requests.

You do not really need a connection pool as everything in Node.js involving I/O including this Redis client is asynchronous. You simply fire off your request and then when the response is ready you are good to go. With this, your app will be handling many concurrent application requests.

Make sense?

I could be wrong but I am not sure. Let's imagine that we are processing 2 incoming HTTP requests coming in pretty much at the same time. The first one uses the client and invoke a GET passing in key1 and passing in a callback function cb1. Under the cover, your client uses a connection and issues a command. While it is waiting for the response, the request for the second client gets processes. If that request uses the same client with a different key and different callback function, I am not sure how your feed parser can differentiate the response from each request separately (specially given that some redis response are coming in as part of multiple chunks). The stream will emit multiple "data" events but I do not think that the order is enforced and it is not clear to me how each data is correlated with the first and second request. The only way I see to do that is to dedicate a connection to a request and wait until the callback for request is complete before we send another request using that same connection.

Have you had the chance to look at how the memcachejs node client is implemented? http://github.com/jketterl/memcachejs The seem to have gone down the path of implementing a Pool, Connection and Request abstraction.

[fictorial]

Redis responds to requests per client in FIFO order. Thus, redis-node-client stores a callback per request/command. When each response from Redis is sent to the redis-node-client, it pops the callback and calls it back with the response.

In your example, the 2 requests are sent to Redis in the order received, and the responses are dispatched in the same order.

The point of the callback is that your application can perform other I/O (reading a file, queueing requests, calling HTTP client requests to some remote server, etc) at the same time waiting for Redis to respond.

I haven't looked at memcachejs. There's no need for a connection pool to a single Redis instance given the above. Connection pools make sense for calls that block; redis-node-client calls do not block. Also, memcache is distributed. Redis is not and is moreover single-threaded.

It make sense now. Thanks for the clarification. Two follow up questions:

1. Do you know if it is possible to gzip.compress content before caching it in redis?

2. I noticed in the ReplyParser.feed that you are currently iterating byte by byte over the inbound buffer. Do you know if it would be possible to optimize both the allocation of valueBuffer and the copy in the case of BULK responses where we now the expected length size? We are storing and retrieving JSON structures with are 30-50K in size and if possible those optimization could end up having a big impact.

Thank again for the coaching!

Edwin

[fictorial]

There exists a node-compress module I believe. See the node modules page in the node.js repo's wiki here on github.

The reason for the byte-by-byte scanning is to make a stateful parser. We are in no way guaranteed that a chunk received by a "data" event contains a full Redis reply. At any byte the end of the chunk could be reached. I don't imagine 30K-50K values having that much overhead given that the Buffer is written in C++ and that the loop is quite tight otherwise. But as always with performance concerns, don't guess, benchmark! If you do find a performance problem, please open an issue.

Thanks!