Redis PUBLISH/SUBSCRIBE channel limits.

9,955 views
Skip to first unread message

Venkatesh

unread,
Jul 28, 2011, 4:57:15 PM7/28/11
to redi...@googlegroups.com
Hi !

Wanted to know if there are any performance measurements with Redis in terms of how many simultaneous subscriptions/channels it can handle? Would appreciate any feedback on this topic.

Venkatesh

Seppo

unread,
Jul 28, 2011, 6:01:25 PM7/28/11
to redi...@googlegroups.com
Hi Venkatesh,
I recommend you to read the documentation of each pub/sub command [
http://redis.io/commands#pubsub ] that has the complexity time of each one.

Just for laziness:

PUBLISH: O(N+M) where N is the number of clients subscribed to the
receiving channel and M is the total number of subscribed patterns (by
any client).
SUBSCRIBE: O(N) where N is the number of channels to subscribe to.
UNSUBSCRIBE: O(N) where N is the number of clients already subscribed to
a channel.
PUNSUBSCRIBE: O(N+M) where N is the number of patterns the client is
already subscribed and M is the number of total patterns subscribed in
the system (by any client).
PSUBSCRIBE: O(N) where N is the number of patterns the client is already
subscribed to.

> --
> 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=en.

Venkatesh

unread,
Jul 28, 2011, 6:14:46 PM7/28/11
to redi...@googlegroups.com
Seppo:

Thanks for the pointer. I did take a look at them. However, my question was more directed towards understanding if anybody had data about how many active subscriptions could a Redis node handle. In an attempt to articulate my question better, think of a simple chat example where by users logging in to the service are available to receive messages from anybody else. In such a scenario, each user logging in would keep a "channel" dedicated for receiving messages for them. In other words, a logging in of a user would result in the user "subscribing" for events on the channel. Anybody wanting to send message to the user "publishes" to the users channel. Should we use Redis as a mechanism for this, the number of channels would increase linearly with number of users. My question was trying to understand if anybody had done any tests/analysis how many such channels (or users in my example) could a Redis node handle and impacts of performance as this increases. Assume my question makes sense :) ?

Venkatesh

To unsubscribe from this group, send email to redis-db+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.
--
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+unsubscribe@googlegroups.com.

Josiah Carlson

unread,
Jul 28, 2011, 6:28:33 PM7/28/11
to redi...@googlegroups.com
You are limited to the number of concurrent connections that Redis can
handle more than anything. If you set the maximum number of sockets
via ulimit, and you configure Redis up to that many, you could
probably have 10k connections without breaking much of a sweat. But I
wouldn't.

I would instead recommend inserting messages into lists (having a
limit wouldn't be unreasonable), adding an expiration time far enough
in the future so that reasonable clients would get the messages, and
having your clients poll those lists every few seconds.

That minimizes the number of concurrent connections, minimizes the
likelihood of memory exploding in the case of a slow client, and means
that you don't need to learn how awful ulimit is to actually use.

This Github Gist implements a poll-based chat server that uses some of
these ideas in order to offer shared chat channels (think IRC without
/msg nick message): https://gist.github.com/1045789

Regards,
- Josiah

>>> redis-db+u...@googlegroups.com.


>>> For more options, visit this group at
>>> http://groups.google.com/group/redis-db?hl=en.
>>
>> --
>> 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=en.
>>
>
> --
> 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.

Reply all
Reply to author
Forward
0 new messages