Thank you for your comment.
Main function of application is only receive data from external source and
distribute that to subscribers. There is little work related to management
of subscriptions beside that it is just sending data.
I tested on windows on one machine. I created one producer with 100 topics
and 10 subscribers. I sent 100k messages from publisher and in case of one
subscriber, subscriber took around 3 to 4 seconds to receive all messages.
On increasing number of subscribers to 10, time also increased to 5 to 6
seconds for each subscriber to receive all messages. Please note that this
testing was done my laptop. I have to test more by running producer on
server and subscribers on different machines to simulate the real
On Tue, Apr 10, 2018 at 1:09 AM, Mark Delany via zeromq-dev <
> > > can have topics around 500 and subscribers could be from 500 to 1000.
> > The only way to know is to test it
> This is true and also measure your system while testing to identify
> potential system bottlenecks. What else is your application doing
> besides making zeromq calls? Is there I/O involved?
> You say you are getting delays. How large are these? How busy are the
> systems when you're getting these delays.
> As a general rule, 1,000 or so TCP sockets is no big deal for a modern
> Unix/Linux kernel. I would also be surprised if 500 topics causes a
> much delay. Even a linear search per message would happen pretty
> quickly on a modern CPU. I am assuming that zeromq does better than
> linear since topics are exact prefix match there are plenty of
> alogrithmic solutions that are far faster than O(n).
> A number of vmstat samples will give a general idea of what's going
> zeromq-dev mailing list
zeromq-dev mailing list