| Oracle® Retail Integration Bus Implementation Guide Release 13.0 |
|
 Previous |
 Next |
The performance of each of these components is influential in the overall performance of the system:
The application server(s) topology and configuration.
The RIB deployment approach.
The hardware sizing and configuration of the RIB hosts.
The hardware sizing and configuration of the applications that are connected to the RIB.
The hardware sizing and configuration of the JMS provider host.
The hardware sizing and configuration of the RIB Hospitals hosts.
There are other factors that determine the performance of the overall system. Some of these factors in a RIB environment are:
Number of channels configured
Number of messages present in the topic
Size of the message
Database clustering
Application Server topology
Number of TAFRs in the processing of the message
Message aggregation
The RIB has to provide guaranteed once and only once processing of business events (message) across the enterprise. Maintaining the ordering of business events across the enterprise is very important from the data integrity point of view.
To provide guaranteed sequencing of message processing RIB requires a guaranteed first in, first out (FIFO) messaging system with guaranteed FIFO rollback. That is, when you rollback the message from the consumer you get the same message back the next time so that it is processed in sequence. JMS Provider provides this FIFO topic and FIFO rollback capability that enables RIB to guarantee message sequencing.
Processing messages in sequence has some overhead as every message has to be checked against the database to find the status of previous messages that it is dependent (same businessObjectid") on. Sequencing requirement creates an inherent bottleneck of ability to process only one message at a time. For example, messages can come at the rate of 100 messages per second but RIB subscribing adapter can process only 1 message at a time in order to preserver ordering. To get around this bottleneck and improve performance RIB provides a few optimizations and functions.
First, RIB processes messages in sequence only when the publishing application wants it to be processed in sequence. The message producer application defines a businessObjectid whose existence informs RIB that this and all subsequent messages with the same businessObjectid have to be processed in order.
Second, parallel logical channels can be created for each message flow paths in the integration system to improve performance. Parallel logical channels are virtual logical message flow paths within the same physical JMS topics. To add additional channels each adapter participating in a message flow must be configured with additional adapter instances. See the RIB Operations Guide on how to configure parallel logical channels.
Parallel logical channel is not the solution for all of your performance problems in the integration system. Parallel logical channels can help only when the corresponding applications integration API is written with non-locking logic and concurrency invocation in mind.
Generally the retail application's integration API's are the biggest factor and bottlenecks in the overall messaging system through put. It is not appropriate to start creating parallel logical channels at the first sign of performance problem. It is critical to analyze your retail applications integration API's first and tuning them before considering the creating of parallel channels.
Parallel logical channel comes with an increase in complexity, more CPU demands and memory requirements, and more operational overhead. They should only be considered when all other components are fully tuned and you are still not able to meet your target numbers.
