Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.
When customers look to increase throughput, one of the recommended approaches is to increase concurrency. More threads producing and consuming messages will generally increase overall messaging throughput - but what if your application has a single (or low) number of threads, what approaches are available and what are the compromises?
The following whitepaper takes a look at some of those approaches and what impact they might provide to your messaging rate.
https://ibm-messaging.github.io/mqperf/MaximisingSingleThreadMessagingRate.pdf
Copy
Sam,
I think it would be good if this article talked a little bit more about the principles involved to help people extrapolate a bit more into how these sorts of constraints might impact their own single thread constrained environments.
In the locally bound non-persistent case a reasonably configured system will be constrained by simple pathlength and CPU speed. No sensible customer would use a fastbound connection for a user written application, and so a shared binding and minimising the number of unneccessary MQI calls is likely the best they can do. MQI statistics are quite handy for comparing the ratio of various MQI calls to get a feel for this sort of efficiency, ideally theses stats would be dominated by the number of MQPUTs and MQGETs. Using the fastest cpu available and disabling hyperthreading are also approaches that should help.
Once you move to a client binding then the CPU speed is secondary compared to the network latency. Streaming messages is the likely biggest opportunity to eliminate network latency, but typically needs to be considered early in any application design.
Your blog only provides results for non-persistent messages, however I suspect that a single threaded constraint is more likely to apply in an environment where strict message ordering is important, and thus is more likely to impact applications using persistent messages. In the case of persistent messages in a single threaded environment then batching messages inside syncpoint can limit the effect of IO latency in much the same way that streaming can be used to reduce the effect of network latency. The disk technology used also has a huge impact on the IO latency, for example synchronous remote replication (as used by native HA or RDQM) would typically imply a much higher latency and therefore more need for either batching or high levels of concurrency (i.e. not single threaded). MQ reports it's perception of IO latency in the LOG stats written to the system topics (see amqsrua), although a more sophisticated interpretation would be needed in a nativeHA environment.
By
Sam Massey
posted