Can we use connection pool in Redis?

[wqhhust]

Does redis support connection pool? Currently we are using 2,000+ java
application servers to connect to mysql (memory engine), and
connection pool is used. If switch mysql to redis, without connection
pool, it can't handle so many connect/disconnect.

[Salvatore Sanfilippo]

Hello,

sorry I'm not really sure to understand what you mean, but I assume
it's a matter of the client library supporting pools of clients to
avoid creating a new connection again and again.

I'll let the Java library client developer to reply about this, but
note that a new Redis connection is *very* cheap compared to a MySQL
one as there is no authentication or other handshake. It's just a TCP
three way handshake.

Cheers,
Salvatore

>
> --
>
> You received this message because you are subscribed to the Google Groups "Redis DB" group.
> To post to this group, send email to redi...@googlegroups.com.
> To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/redis-db?hl=.
>
>
>



--
Salvatore 'antirez' Sanfilippo
http://invece.org

"Once you have something that grows faster than education grows,
you’re always going to get a pop culture.", Alan Kay

[Sergey Shepelev]

Redis supports peristant (keepalive) connections.

Your favourite or your own Redis client library may implement a connection pool.

But the best way would be to actually have one connection per
application life. A pool of 1 connection.
In Java it may be implemented as a static class with synchronized
executeCommand() method. It tries to send command to your Redis
server, if that fails for network reasons, it reconnects and tries
again. That covers initial (not connected yet) case too.

[Alex]

And what if there are a huge number of clients? Will a 100 or 1000
persistant connections be a problem? Is there any upper (performance)
limit (32 bit port number)?

On 22 Nov., 15:14, Sergey Shepelev <temo...@gmail.com> wrote:

[Sergey Shepelev]

On Sun, Nov 22, 2009 at 5:30 PM, Alex <alexg...@gmail.com> wrote:
> And what if there are a huge number of clients? Will a 100 or 1000
> persistant connections be a problem? Is there any upper (performance)
> limit (32 bit port number)?
>

Hundreds will not be a problem.
Tens of thousands will be.

See, serving tens of thousands of clients with a single box will be a
problem anyway. And it will be a much worse problem if all clients
were to establish new TCP connection for each request. So, no,
persistant connections don't implicitly create a problem.

There is an upper limit of 64k open ports, yes. AFAIK, this is not
bound to 32 bit versions of Linux. But maybe other OS have this limit
higher.

I believe it would make a lot of sense for Redis to use UDP or
stateless SCTP for at least some of the commands which operate a small
amount of data, like push, pop, list length command. But that would
greatly complicate client libraries and profit of using stateless
protocol is only worth that for a truly high-loaded systems, like
Facebook, you know, those giants.

[Joubin Houshyar]

Alex,

In JRedis you have two options if you are using a front-end that
serves a lot of concurrent processes.

For low (concurrent) number of processes (threads), you can use
JRedisService. This connector maintains a pool of connections to
Redis and cycles through next available connection to serve service
requests.

For very high (concurrent) number of processes (thread count in the
thousands) -- specially if you will be maintaining a constant load on
the connector -- use the Pipeline with sync() semantics. Pipeline
uses a single connection, but has much higher throughput.

/R

[wqhhust]

Yes, there are thousands of connections. That's why I am looking for
connection pool.

On Nov 23, 1:04 am, Sergey Shepelev <temo...@gmail.com> wrote:

[wqhhust]

Thanks for your suggestion, I am looking at the pipeline.

[Sergey Shepelev]

On Mon, Nov 23, 2009 at 6:22 AM, wqhhust <stayw...@gmail.com> wrote:
> Yes, there are thousands of connections. That's why I am looking for
> connection pool.
>

My point:

* More than 1 connection from single client (process) to single Redis
does not make sense at all. You don't win a thing if you make more
than one connection. So you always need a pool of single connection.
Is that still a connection pool?
* Thousands of different clients connecting to single Redis does not
relate to connection pool. Thousands of different clients is a server
problem.

[Joubin Houshyar]

> * More than 1 connection from single client (process) to single Redis
> does not make sense at all. You don't win a thing if you make more
> than one connection.

Sergey,

That's not true. If the client you are using is providing synchronous
request/reply semantics, then your N requests must line up. The most
expensive costs are the network IOs. If you have more than one
connection, you can be writing in one while reading from another.
(Redis is indeed single threaded, but after it send the response to
one connection it is ready to read (from OS buffers) the latest
packets from another connection. Redis handles it with grace.
(Obviously there must be a ceiling to the number of connections it can
manage).

Proof of this is running N threads against one JRedisClient connection
vs N threads against one JRedisService with Nc connections. You most
definitely get higher throughput and lower latencies per request
serviced.


On Nov 22, 10:35 pm, Sergey Shepelev <temo...@gmail.com> wrote:

[Sergey Shepelev]

On Mon, Nov 23, 2009 at 7:42 AM, Joubin Houshyar <sun...@gmail.com> wrote:
>> * More than 1 connection from single client (process) to single Redis
>> does not make sense at all. You don't win a thing if you make more
>> than one connection.
>
> Sergey,
>
> That's not true.  If the client you are using is providing synchronous
> request/reply semantics, then your N requests must line up.  The most
> expensive costs are the network IOs.  If you have more than one
> connection, you can be writing in one while reading from another.

I'm sorry, i actually didn't use Java Redis client, i'm talking more
about network peers in general.

If the client is providing synchronous *semantics*, it is a useful
feature, it is nice. Writing

c.write("command");
reply = c.read();

is much simpler to understand, much better than breaking code into
callbacks like

c.write("cmd", onsuccess, onerror);

But if client is truly making synchronous connect/read/write under the
hood, it is done wrong, sorry.

See, e.g. in Python libraries called gevent/Eventlet/diesel/etc allows
you to continue use synchronous semantics while they actually use
asynchronous sockets under the hood, thus combining best of two
worlds: nice semantics and good performance.

[Joubin Houshyar]

On Nov 23, 6:58 am, Sergey Shepelev <temo...@gmail.com> wrote:

> On Mon, Nov 23, 2009 at 7:42 AM, Joubin Houshyar <suno...@gmail.com> wrote:
> >> * More than 1 connection from single client (process) to single Redis
> >> does not make sense at all. You don't win a thing if you make more
> >> than one connection.
>
> > Sergey,
>
> > That's not true. If the client you are using is providing synchronous
> > request/reply semantics, then your N requests must line up. The most
> > expensive costs are the network IOs. If you have more than one
> > connection, you can be writing in one while reading from another.
>
> I'm sorry, i actually didn't use Java Redis client, i'm talking more
> about network peers in general.

That's fine. I was responding to your statement regarding the merits
of having more than a "single client (process) to single Redis
[server]", which was false (regardless of the client implementation
language).

> If the client is providing synchronous *semantics*, it is a useful
> feature, it is nice. Writing

Redis protocol has some interesting features (which greatly ease
adoption):

- it is a request/reply protocol.
- there is no distinction between physical and logical clients.
- (thus) There is no distinction between physical and logical
messages.

(Fire up a telnet session: what you see is what you get. (Type
really fast (/g/) and you will see pipelining in action.))

So what this means is that synchronous client semantics are a natural
expression of the redis protocol. To provide asynchronous semantics
on the client side, the client needs to provide the magic.

> But if client is truly making synchronous connect/read/write under the
> hood, it is done wrong, sorry.

I suggest you try implementing a barebones client (in the language of
your choice) using an event based IO lib that provides PING, SET, GET,
and EXISTS commands for a concurrent set of processes using a single
connection. That exercise would shed some light on the topic at hand.

Event based network IO addresses server side issues (e.g. C10K) and
brings little to the table on the client side beyond unnecessary
complexity.

> See, e.g. in Python libraries called gevent/Eventlet/diesel/etc allows
> you to continue use synchronous semantics while they actually use
> asynchronous sockets under the hood, thus combining best of two
> worlds: nice semantics and good performance.

http://www.netstate.com/states/intro/mo_intro.htm

[Sergey Shepelev]

Alright, i got it now. You're talking about the problem of
multiplexing different logical clients over single physical
connection.

Yeah, good exercise, thanks, i must do it.