| Oracle® Retail Integration Bus Implementation Guide Release 14.1 E57321-01 |
|
 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
See "Performance Considerations" in the Oracle Retail Integration Bus Operations Guide.
|
Note: For more information, see ”Performance Considerations,” in the Oracle Retail Integration Bus Operations Guide. |
The RIB must provide guaranteed once and only once processing of business events (messages) across the enterprise. Maintaining the order of business events across the enterprise is critical to data integrity.
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, which enables RIB to guarantee message sequencing.
Processing messages in sequence results in operational overhead, as every message must be checked against the database to find the status of previous messages on which it is dependent (same businessObjectid). Sequencing creates an inherent bottleneck, in that only one message is processed at once. For example, messages can come at the rate of 100 messages per second, but a RIB subscribing adapter can process only one of those messages at a time to preserve the order. To get around this bottleneck and improve performance, RIB provides options for optimization and functionality.
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 Oracle Retail Integration Bus Operations Guide for how to configure parallel logical channels.
Using parallel logical channels is not the solution for all performance problems in the integration system. They can help only when the API for the corresponding applications is written with non-locking logic and concurrency invocation in mind.
Generally, integration for the retail application APIs are the biggest factor for bottlenecks in the overall messaging system throughput. It is not appropriate to start creating parallel logical channels at the first sign of performance problem. It is important to analyze and tune the integration APIs of the retail applications before considering the use of parallel channels.
Using parallel logical channels increases complexity, CPU demands, and memory requirement, resulting in more operational overhead. Use them only when, after all other components are fully tuned, you are still not able to meet your target numbers.
