Tuning multiplexers for optimal performance
The load of batching, conflating and merging messages being sent from publishers to
outbound clients is spread across client multiplexers. The number of configured client
multiplexers must take into account the expected message load and concurrent client
connections. The more clients are assigned to a multiplexer the more load it must
By default, the number of client multiplexers is equal to the number of cores on the
host system of the Diffusion™ server
A client multiplexer processes all client messages into the client
queue. Clients are added to the multiplexers according to a round-robin load balancing
Publishers either broadcast on a topic to all subscribed clients or
send clients direct messages. When broadcasting all multiplexers are notified and go on
to find all subscribed clients which are assigned to the particular multiplexer. When a
message is sent to a particular client only that client's multiplexer is notified. It is
more efficient to broadcast than it is to send the same message to a large number of
clients by iterating over them.
Client multiplexers are non-blocking, high priority threads so having too many can be
detrimental, as they are competing for the same resource (CPU). As a rule of thumb, the number of multiplexers
must not exceed the number of available logical cores. If a client multiplexer becomes
over-subscribed, message latency can increase. For maximum throughput, the number of
multiplexers can be set to the number of available cores, but this configuration is only
recommended in the case where other threads are assumed to be mostly idle (for example,
little inbound traffic, low publisher overhead).
Client multiplexers performance is influenced by the use of merge and conflation policies
as those are executed in the multiplexer thread. It is recommended that conflation
policy changes and in particular changes to merge conflation logic be profiled and
written with performance in mind. In particular the use of locks or any other blocking
code is highly discouraged.
Each multiplexer uses a different buffer for each output buffer size that is specified to
any connector. If there were three connectors with different output buffer sizes
specified, each multiplexer assigns three different buffers. Each multiplexer might also
assign an extra buffer for HTTP use. A larger output
buffer enables more efficient batching of messages per write, as large writes are
generally more efficient but care must be taken to not overwhelm client connections
regularly and causing them to be blocked for any period of time.
When a multiplexer is unable to write a message to a client because the buffer has become
full, a selector thread is notified. The selector thread is responsible for watching the
client and notifying the multiplexer when it becomes writable. The multiplexer remains
responsible for writing the message.