How Many Client Subscriptions Can SingleNode Handle?

I am looking at modifying our architecture a bit since I was totally mistaken about using ES as a queue, at least for read models. Is one subscription per projection reasonable? If so how many?

What numbers are you talking about?

Subscriptions are pretty fast already, I’d expect few thousands of them doing fine, but I haven’t stress-tested them yet.

! Time to see if I can get rid of rabbitmq :slight_smile:

How difficult would it be to have an api like: SubscribeToStreams(new []{"$et-EventType1",$et-EventType2"}, …). Combine that with Handles and we can get a convention based per projection type subs :slight_smile:

We’ve tried using it as a broker in a few cases, it works well as a substitute for Rabbit MQ.

What are typical latencies for individual messages of moderate size, e.g. <1k?

Just wrote quick and dirty test: created 200000 subscriptions to different streams (on one EventStoreConnection). In another thread did wrote few millions test event to those streams.

Everyone were doing fine (except sometimes TCP connection send queue was too big and TCP connection was closed (and reconnected)).

So the bottleneck is still writer, not subscription service.

Though, that is artificial test on loopback, but still I don’t see problems with handling many subscriptions (they are really cheap and the main bottleneck is sending data over TCP connection).

What are typical latencies for individual messages of moderate size, e.g. <1k?

It depends on your hard drive. On my local machine with SSD the results are as follows. The tests were done over loopback, so over real network latencies may be bigger, of course.

I did 5000 (except for 1m events) sequential writes over one connection and averaged total time among those writes. Here are results. Please, take them with a grain of salt.

Event data + metadata size Results

100 bytes 5000 requests completed in 13548ms (369,06 reqs per sec, latency: 2,71 ms).

1000 bytes 5000 requests completed in 13633ms (366,76 reqs per sec, latency: 2,73 ms).

10000 bytes 5000 requests completed in 15605ms (320,41 reqs per sec, latency: 3,12 ms).

100000 bytes 5000 requests completed in 42455ms (117,77 reqs per sec, latency: 8,49 ms).

1000000 bytes 1000 requests completed in 23321ms (42,88 reqs per sec, latency: 23,32 ms).

Likely you would want to just subscribe all here :slight_smile:

varies from machine to machine but here for smaller messages I am seeing ± 10ms (end to end, eg including the write internally)

Even if I have multiple handlers in the same proc? Like if I had 5 projections I would want each one to know where it left off separate from the others. If I had 50 I would want to minimize traffic also.

Each can save its checksum on its own. When restarting just look to see if they need it again. With 50 projections you probably want all anyways.