Improve Message Performance Under High Volume with Low Latency Consumers
------------------------------------------------------------------------
Key: CXF-2343
URL: https://issues.apache.org/jira/browse/CXF-2343
Project: CXF
Issue Type: Improvement
Components: Transports
Reporter: Paul Hadrosek
IT organizations are on constant pressures in improving enterprise messaging
systems to deliver and process high volume message traffic. For example
financial IT organizations are continually automate, integrate and optimized
the transaction life cycle. The underlying messaging system must be able to
support extremely low latency and very high message throughput with effective
congestion control.
Message performance testing was performed to evaluate the CXF bogus message
selector implementation as the best approach in improving message throttling in
a long consumer service process with a very high JMS message traffic volume.
The intent of the bogus message selector implementation in CXF is to alleviate
message throttling by delegating incoming messages to under performed consumer
services. Testing was performed on the CXF bogus message selector
implementation with a commercial JMS message broker. The test scenario
simulated an ingest driver that produced high volume message traffic with a
long running CXF consumer service which forced a backlog of messages in the
request queue. The test results illustrated a dramatic degradation in the
commercial JMS message broker processing performance from 12,000 messages per
second to 100 messages per second (99.17% degradation of performance). Also it
was observed the JMS receiveTimeout parameter was set to the default value of 1
which contributed to the degradation of performance. CXF was modified to expose
the JMS receiveTimeout parameter as a CXF feature. The test scenario was rerun
with a receiveTimeout set to 30 seconds which improved message processing from
100 messages per second to 4,918 messages per second.
To further improve ingest message processing performance; the bogus message
selector implementation was replaced with a stop and start Spring JMS Listener
Container (DefaultMessageListenerContainer) implementation via the CXF
JMSContinuation class. The JMSContintuation class starts and stops the Spring
Container based on the maximum suspended continuations parameter. The moment a
stop is issued from the JMSContinuation class to the Container, no new messages
are allowed to be accepted by the Container until the Container completes
processing the suspended messages. To avoid message loss while the Container is
in the stop state, CXF features must support the JMS
acceptMessagesWhileStopping parameter. This parameter must be set to true to
notify the Container not to reject messages while in the stop state. The test
scenario was rerun using the CXF start/stop Container implementation with a
commercial JMS message broker. The test results demonstrated that message
processing performance improved from 4,918 messages per second to 8,333
messages per second.
Based on the test results, I concluded that the start/stop Container
implementation is the recommended solution for improving message performance in
high JMS message traffic with low latency consumers. The start/stop Container
implementation improved message processing performance over the bogus message
selector implementation by 28%.
See attachment for patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
