Excuse me for my basic question, but I didn't find my answer in my Google searches.
I want to develop a server which should respond to hundreds of clients. Each client may send tens to hundreds of messages per second.
I want to know if I use queuing protocols such as AMQP (RabbitMQ implementation) or ZeroMQ, how many TCP connections the server should supports?
Is it the total number of clients or total number of messages per second?
Nota Bene: ZeroMQ is definitely not a "queuing"-protocol. One shall rather think about it to be a powerful framework of low-level building blocks [primitives] that enable designers setup very fast and rather abstract behaviour-oriented designs for advanced use-cases from Messaging per se to a robust, non-blocking, asynchronous, distributed systems concurrency signalling and content-related transport + controls. Indeed a powerful set of tools, believe me.
AMQP is a Broker-based approach
ZeroMQ is Broker-less solution
Message count per se does not typically create a problem.
Their associated processing typically does.
Limit No.1: operating system TCP-settings constraints
Solution: review your system documentation for limits to work within and setup/tweak values, on the OS-level, as appropriate.
Limit No.2: growing end-point's process delay(s) grows also a risk of RECV/SEND buffer overflow(s).
Solution: review your code-architecture whether it can increase the transaction-performance ( be it by a distributed pipe-line processing or by a load-balancer to distribute the flow of incoming connections / transactions onto multiple target worker-units ).