how many connections that PUB/SUB can handle?

[remus hoop]

if subscribe 10000 channles , performance is good? whats the usage memory?

thx~

[Salvatore Sanfilippo]

On Fri, May 20, 2011 at 4:11 AM, remus hoop <remus...@gmail.com> wrote:
> if subscribe 10000 channles , performance is good? whats the usage memory?

This is how Pub/Sub works performance wise in Redis.

You have two things.

1) Subscribers to channels (SUBSCRIBE)
2) Subscribers to *patterns* (PSUBSCRIBE)
3) Publishers (PUBLISH)

You can consider the work of subscribing/unsubscribing as a constant
time operation, O(1) for both subscribing and unsubscribing
(actually PSUBSCRIBE does more work than this if you are subscribed
already to many patterns with the *same* client).

All the complexity on the end is on the PUBLISH command, that performs
an amount of work that is proportional to:

a) The number of clients receiving the message.
b) The number of clients subscribed to a pattern, even if they'll not
match the message.

This means that if you have N clients subscribed to 100000 different
channels, everything will be super fast.

If you have instead 10000 clients subscribed to the same channel,
PUBLISH commands against this channel will be slow, and take maybe a
few milliseconds (not sure about the actual time taken). Since we have
to send the same message to everybody.

Also, if you have clients subscribed to 10000 *patterns* publish will
be slower than usually, but the work to do for every existing pattern
is smaller compared to the work that there is to do for every client
*receiving* the message.

About memory, it is similar or smaller than the one used by a key, so
you should not have problems to subscribe to millions of channels even
in a small server.

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

--
Salvatore 'antirez' Sanfilippo
open source developer - VMware

http://invece.org
"We are what we repeatedly do. Excellence, therefore, is not an act,
but a habit." -- Aristotele

[remus hoop]

Amazing!
thank you very much!

I'll have a try immediately.

2011/5/20 Salvatore Sanfilippo <ant...@gmail.com>

[Kashif]

Interesting, anteriz that was insightful!

What about another twist:

Say if I have 10 Million distinct subscriptions, and I have 10
clients, where each client is listening to 1M different subs.

Now a client publishes event to distinct subscription (out of a
million) - is that still O(1) operation?

Example:

client 1 - subscribe event1, event2, event3, .... event N, where N =
1M
*after*
client 2 - publish event1 *some-message*
Is this publish by client 2 O(1)?

kashif


On May 20, 4:13 am, Salvatore Sanfilippo <anti...@gmail.com> wrote:

[Josiah Carlson]

The amount of time to create the subscriptions for a particular client
is O(number of subscriptions for that client). The amount of time to
send a message to a particular channel is O(number of subscribers to
that channel).

So the initial subscribe in your described case would be slow to
finish, but the actual publishing would be fast.

- Josiah

[Kashif]

Thanks Josiah!

I'm trying to create a sort of messaging server - where users connect
to AppServer, and AppServer creates subscription for every users.

When you have users connected to different AppServers, and sending
messages between each other, you can have Redis work like in-memory
mailbox.

kashif

[George Blazer]

Great thread.

So just to iterate, it's better to have million channels with one/two subscribers each than a million users listening to one channel and parse the data right?

[Josiah Carlson]

You really mean "reiterate", but yes. But the reasons are simple: if you publish to 10k clients (1 million would suggest that you wrote your clients wrong), then the amount of data that needs to be sent is 10,000 times what was received, which can be pretty nasty for the network and Redis. But sending to a handful of clients? Not a big deal.

 - Josiah

P.S. The company I used to work for used the Soti's Mobicontrol product on Android. If you can find a fully-supported device, it's a good MDM solution.

To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.

To post to this group, send email to redi...@googlegroups.com.

Visit this group at http://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/groups/opt_out.