cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Hadrosek (JIRA)" <j...@apache.org>
Subject [jira] Created: (CXF-2343) Improve Message Performance Under High Volume with Low Latency Consumers
Date Thu, 16 Jul 2009 11:28:14 GMT
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.


Mime
View raw message