Scenario
You have a system that is publishing small messages to the same topic as fast as it possibly can.
Question
What is the impact of creating new
Session
s on the publishing performance?Disclaimer
Please don't consider this a generic SonicMQ benchmark in any form. The code and infrastructure were definitely not setup for a proper benchmark, and I'm sure my employer signed some disclaimer that we wouldn't perform one anyway. This is just an example of how coding practices can affect your performance. Blah Blah Blah don't sue me Blah Blah Blah.
Benchmark Description
- Create a JMS
Connection
to your SonicMQ broker. - In a tight, single-threaded loop, construct a new
BytesMessage
, bung 10 bytes of data into it, and send the message. - Every N messages (where N is varied), shutdown the
Session
and construct a newSession
,Destination
, andMessageProducer
.
Minutae
- SonicMQ broker was running on a 2-socket dual-core (total of 4 cores) Opteron machine running Solaris 10 x86
- Broker running 7.5.1, 7.5.0 JMS client
- Client was running Windows XP
- JDK 1.5.0_13 used on both broker and client
- 100Mbps available between client and server (broker has 1Gbps available; I'm not allowed to thrash this broker to death during business hours), going through at least 3 switch hops (but no router)
- All messages sent non-persistent, with no consumers whatsoever
Results
New Session Every # Messages | Msg/sec |
---|---|
10 | 4400 |
100 | 18653 |
1000 | 31113 |
10000 | 33074 |
100000 | 33507 |
More interestingly, if you look at the network utilization graph on the Windows machine acting as the test driver, you can see exactly how the performance ramped up:
Conclusion
There appears to be some definite network latency in setting up the
Session
, MessageProducer
, and Destination
, but this disappears beyond the every-1000-messages mark.Therefore, you can quite clearly conclude that you should avoid creating unnecessary Sessions and just hold them open for a publishing scenario.